Where do you go when you want to find a library or component that performs some specific function you need? Do you go to one of the many open source hosting sites like CodePlex, Google Code or GitHub? Or do you just Google/Bing until you stumble upon something that might work, try it out, find out it doesn’t, rinse and repeat.
What do you do when you’re looking for an API or third-party commercial component to integrate with your apps? More Googling, more trying things out, more wasting time.
The problem is there’s no central directory of these sorts of things. Nothing where people can rate and review projects to give you some idea of whether or not they’re worth your time. Nothing to separate the wheat from the chaff. The Toolbox section of the ASP.NET site would be a great place to centralize all of these things but limited to just stuff that works with ASP.NET.
It could be community-managed (like a structured wiki) but offer the option for specific entries to be “claimed” by their owners. Only users with sufficient reputation (earned throughout the site) would be able add entries or make changes.
Open Source Project Directory
I’d like to have a better way to locate good open source libraries (I’ve seriously considered building this for Managed Assembly and it still might happen). They’re currently all spread out across different hosting sites so a central directory would make them easier to find.
Each project can add links to their project home page, downloads, issue tracker, mailing list, etc. They could also provide their RSS feed URLs so the latest news from each project could be displayed right on their listing.
Visitors would be able to add favorites/follow/become a fan of projects which could provide for customized news feeds for just your favorite projects. Users would be able to rate and review projects as well. In addition to favoriting (which is for personal use), users could select ‘I Use This’ to publically show their support for projects. Ratings + reviews + user counts would help narrow the list when trying to find the right OSS project for your needs.
This is essentially what Ohloh does, but I’d like it specific to projects that work with ASP.NET. Like other parts of the site, this could be a subset of a larger directory that is for all of .NET.
API Directory
Similar to the open source project directory would be a directory for APIs that work with .NET. There are so many useful APIs out there that people don’t know about. Companies would jump at the chance to increase exposure for their APIs. They can provide getting started articles, code samples, etc. APIs would be able to be reviewed and rated just like open source projects.
Commercial Product Directory
This might very well not be even remotely feasible and considering the hubbub over ads on the home page, it’s a treacherous topic to even broach. But I’ve been operating in a “in a perfect world” mentality since I started this series, so keep that mind here.
Like the open source project and API directories, I’d like to see another directory of commercial products built to work with ASP.NET. This would operate identically to the open source directory above, just separated so that it’s clear that these entries cost money.
Would the community take the time to list commercial products? Would it even be useful for finding the right tool for your project? Would vendors support such a concept? This is probably the most risky of any idea I’ve proposed, but I think it would work and be extremely valuable.
A Place for Ads
This is the place on my version of the site where ads make complete sense. You’ve got people looking for tools. They’re in the right mindset and they’re actively searching out new things. Ads could actually be useful to them. They don’t disrupt what the user was trying to do (unlike the home page). Advertisers might not get the same number of eyeballs, but the ones they do get would be highly-targeted.
Conclusion
And so this little project comes to an end. I’m happy with how it turned out. I had a lot of fun thinking through each section and am glad to hear that it caught the attention of the people who are in a position to make changes. Microsoft deserves credit for the recent progress they’ve made with the lightweight MSDN view, the Web Application Toolkits, the MSDN Beginner Developer Center, etc. and I’m sure they have a lot more in the works.
If you’ve been reading my blog for awhile, this post will contain some things that sound familiar to you. The goal for this section of the site is to provide a mechanism for the community to congregate. I’ve already attempted to do that with ManagedAssembly.com. Many of the ideas in this section have come out of my experience building that site. In fact, I would suggest reading the reasoning behind creating Managed Assembly before continuing with this post.
The primary goal of the Community section is to give developers a reason to keep coming back to the site. The way to keep them coming back is to consistently provide fresh content to discover and discuss. Social news sites are perfect for aggregating blog posts and articles and promoting the best ones. But there’s a lot of good content that only exists in Twitter streams. The .NET community has a particularly good Twitter community going, so we need to tap into that as well.
Aggregating and organizing ASP.NET-related content
Social news sites like Digg, Reddit, Hacker News and others have become a standard way to aggregate and share content. The .NET community even has at least four (that I’m aware of) of these types of sites. The current ASP.NET site is already attempting to aggregate the best content, but why not outsource that to the community? The .NET social news sites have proven that it this type of thing has value. The very best items can be promoted on the home page which could result in significant traffic for content producers, likely leading to more quality content.
While all the current .NET social news sites do a good job of promoting quality content, none of them have a big enough audience to spark discussions. Only a very small percentage of users will comment on a given post, so you need a critical mass of users to have meaningful discussions. The ASP.NET site already has the traffic to allow for this. There will be people who try to game and spam the system but that can be overcome with a proper moderation system. Hacker News and Stack Overflow have proven that gaming and spam can be managed at a large scale.
Hacker News allows people to submit either a link or a topic to be discussed. One common type of discussion topic is a request for reviews of a project that was built by the poster. I’d like to see this for .NET projects. Most people know about the high-profile sites that use .NET, but I want to hear about what you built with ASP.NET MVC, jQuery and IronPython over the weekend just for the heck of it. There’s a lot that can be learned from seeing how people actually built something and how they used the tools we all use every day in some unique way to accomplish something you didn’t think was even possible.
I think the next evolution of the standard voting sites will be Twitter integration (or whatever the next real-time distributed discussion method is). You could track links posted by Twitter users who are known to post ASP.NET content and then automatically present those stories to be voted on if enough people tweet and retweet them. Nothing would be auto-published without being reviewed by the community but it was provide an easy way to find new links quickly after they gain traction on Twitter.
How do you get a list of ASP.NET Twitterers? Let them opt in. Right now there’s no good way to find other ASP.NET Twitterers. Why not create a directory of them? Take that directory and use it as a starting point to scan for links (with the users’ permission of course).
Once you have a list of all the Twitterers you can do more than just harvest links. Twitter’s trending topics are a complete wasteland now, but trending topics specific to a community? That would be interesting, especially during special events like MIX and PDC.
If you really wanted to take it to the next level, have human editors pick the best Tweets and feature them on the home page. Give people that are creating quality content the exposure and recognition they deserve. Let a couple people have access to the account that’s pulling the tweets, tell them to favorite the best ones and feature them.
All these Twitter-related features exist to pull value out of the places existing conversations are happening and repackage it for people who are new to the community, refuse to use Twitter or don’t have time to invest in following Twitter more closely.
Now that we have the ability to find the best blog posts, articles and Twitter content, there’s only one more type of content that changes often enough to be worth organizing: podcasts. The current site lists the latest episodes from popular podcasts which is a good start. I would expand that to include episode ratings and discussions and provide a more organized view of a podcast’s metadata and episodes (like iTunes).
Coordinating real-life events
How many *good* user group web sites have you been to? I haven’t seen that many. If you want people to get together and talk about your technology, why not provide them the tools to do so? A simple user group web site and registration manager, tied in with a directory of user groups and their associated events would help a lot of groups be better organized and get more attendees. Upcoming meetings can be listed on the home page, helping with publicity that can often be hard to generate on your own. These tools should actually be part of a larger solution that spans product lines, with each subset hosted on the specific site it pertains to.
Please chime in with your thoughts below. Tomorrow I’ll wrap up this series with ‘The Toolbox Experience’.
There are three parts to the overall Support Experience:
- Getting Started
- Documentation
- User-to-user support
Getting Started
As I identified in the previous post, getting new users started quickly is the top priority for the site. Because of this the ‘Getting Started’ section gets its own spot on the main navigation and all the links from the home page for new users lead here.
Note: I wrote this a couple days ago before I knew the MSDN Beginner Developer Center existed which looks like a great resource and meets most of the needs I describe.
New users come in all forms. They could be completely new to programming or be an experienced programmer new to the web. They could be familiar with web development but know nothing about .NET and ASP.NET. Each type of user requires a different starting point and progression:
If you’re new to programming you need a lot of info to get started. The site should provide a basic overview of everything you need to get going: HTTP, HTML, CSS, JavaScript (what it is and does instead of how to write it to start), etc. In an ideal world, no one would even get to the point of downloading Visual Studio without knowing how these fundamentals work. Microsoft obviously knew I was going to write about this since they very recently launched the MSDN Beginner Developer Learning Center. The only thing I would change in the Web Track is to move the web basics before the Visual Studio Express basics. Regardless, this content should be co-opted and reused on (or even better, moved to) the ASP.NET site using the same branding.
Sidebar: Why use the same branding?
As much as possible the ASP.NET site should avoid linking out to other Microsoft sites. It should be the only place you need to go for learning and reference material related to ASP.NET. You shouldn’t have to jump around MSDN developer centers, MSDN docs, CodePlex, Channel9, etc. If a site doesn’t reliably give you the information you need quickly when you feel it should, you subconsciously decide not to use it. Causing a context switch is a great way to trigger the feeling of dissatisfaction. Every time you switch sites or branding, you have to reorient yourself. It’s an unnecessary burden on the user. Over time that feeling of ‘slogging through’ has a negative impact on user experience.
All the existing starter content can be reused, with some minor changes to organize it better (grouping by skill level most notably). I would also add some videos and walkthroughs that show building actual application features people are already familiar with instead of showing how to do specific programming tasks (e.g. build a blog vs. displaying a grid).
Documentation
Along those lines, all relevant MSDN docs should be hosted within the site. The current forums are handled this way: only the relevant subforums from the MSDN forums are listed directly on the ASP.NET site. In the same way, only the subset of the MSDN docs that pertain to ASP.NET should be shown right on this site itself, preferably using the content of the MSDN Lightweight view with the frame of the ASP.NET site.
The docs should be prominently featured on the main ‘Support’ page. I don’t understand why the current site doesn’t put any emphasis on links to the docs. Experienced developers coming from other frameworks will expect to have documentation readily available. Check the sites for Django, Rails and PHP. Notice anything in common about what each framework’s main navigation contains? ‘Documentation’
User-to-User Support
I’m a huge StackOverflow fan. They’ve nearly perfected Q & A on the web. In my ideal ASP.NET site, the forums are completely replaced with either a knock off of StackOverflow or a StackExchange install. Anyone that’s used the MSDN forums and StackOverflow knows there’s no comparison. StackOverflow blows it out of the water in every way. You can integrate the user-to-user support with other parts of the site too, like featuring popular questions on the main Support page. I would love to write a lot more about fixing the user-to-user support options, but this is really all I think there is to it.
With a clearer focus, better organization and a better user-to-user support system, the ASP.NET would offer much more compelling reasons for experienced users to return for help.
This was a fairly uneventful section of this exercise but things will pick up in Part 3 when we take on integrating social media concepts into the site.
Before I begin with Part 1, I want to add an additional disclaimer. The ideas I present in these articles are not necessarily new, clever, novel, etc. Many times I will be describing a feature that already exists in some form either on the ASP.NET site itself or other sites (including competing frameworks). I do not intend to take credit for each feature presented. My goal is to combine the best ideas and features to create a whole that is more valuable than its individual parts.
The Home Page Experience
A good home page quickly moves a user closer to their final destination on a site. On the ASP.NET site, the home page presents a unique challenge: how do you adequately serve both new users who have no idea about the what, why and how of ASP.NET and experienced users who have come back to get the latest info or interact with the community?
This leaves us with two somewhat competing goals:
- Guide new users to the appropriate ‘Get Started’ section for their skill level.
- Provide an overview of what’s new and notable in the community.
With these goals in mind, I put together a mockup of what the home page could look like. I Am Not a Designer™ so it’s intentionally light on the polish. I put this together to demonstrate intent and no more (as you can see by my egregious use of copy and paste). Think of it more as a sketch than an actual design. I just happen to sketch with Fireworks 8.
Guiding New Users
The goal list above is a little misleading. If I could more accurately prioritize the goals of the home page, it would look more like this:
- Help new users
- Help new users
- Help new users
- Help new users
- What’s new and notable
Since it’s by far the most important goal of the home page, it needs to be the most prominent part of the page. We can’t account for everyone, but I think there are three major types of new users: complete beginners, experienced non-web developers and web developers familiar with other development stacks. Every type of new user needs to be able to quickly find relevant information tailored to their experience level. (I’ll cover the needs of the different types in more detail in Part 2.) It should be immediately obvious where their starting point is.
Once a user has moved beyond needing the introductory material, they can hide that content area and allow the other features to move into a more prominent position on the page. Or the beginner stuff can be replaced with more advanced material.
What’s New and Notable
The www.asp.net needs to be the authoritative source for the latest official news and announcements. When something is announced, you want the first place people check to be the official site. You have to earn that trust though by posting consistently high-quality and relevant content in a timely manner. This is the perfect opportunity to create an official ASP.NET blog.
ScottGu’s blog is current serving this purpose. A lot of what he writes could be moved to the site as a post on the official ASP.NET blog. Having the posts on Scott’s blog works for those of us who know he is and how he fits into the overall scheme of things, but if you’re not familiar with the org structure of DevDiv the posts would carry more weight being on the main site. Scott puts out such great content. It deserves more than a link to a community blog site sitting on a subdomain.
Google really excels in this area. All their major products have their own blogs that are frequently updated with quality information. If something is wrong with Gmail, the Gmail blog is the first place you go (after complaining about it on Twitter) to find out what’s up. If there are new features, they’re announced there. For the most part, we’ve been conditioned to trust that the Google blogs will give us the information we need, when we need it.
The rest of the home page is designed to aggregate the most noteworthy content from the rest of the site. The community/social features will be covered in Part 3 and the toolbox features will be covered in Part 4.
Ads
If you’re familiar with the current site, you’ll notice one huge difference in my mockup from the current site. There are no ads in my design. This is 100% intentional. Microsoft has repeatedly drawn fire for including ads on this site. Unfortunately Microsoft’s reasoning is hard to defend. The justification that the ads exist to offset the cost of running the site is indefensible for a company Microsoft’s size. There have been other reasons proffered as well, but I don’t think any of them are compelling enough to justify having ads on the home page. They do nothing to serve either of the primary goals I identified above; in fact they detract from them.
Let’s look at it from the perspective of someone with PHP experience that has started a new job and needs to get started with a new project that has to be ASP.NET. When they head to the site, do you want to distract them with hosting offers or do you want to get them up to speed as quickly as possible?
Putting ads on a site also changes the relationship between the user and the site. Visitors are indirectly informed that they’re there to be sold to. When you want to learn something new, do you want to wade through a sales pitch or get right to the tutorials? If you’re trying to sell someone on using your framework, do you want to simultaneously sell them something they don’t need yet?
There are places in my redesign where ads will find a home and feel more natural and complementary to their surroundings instead of distracting. The home page is just not the place for them. You’ll see in the mockup that a commercial product is featured in the toolbox features. This is not an ad. It will be explained in Part 4.
Thus concludes Part 1. In Part 2, I’ll cover the ‘Get Started’ and ‘Support’ sections and what the experience should be like for learning and getting help.
What do you think? What should be on the home page? What shouldn’t be on the home page? Do you agree with the priorities and goals I’ve set? Let me know what you think.
I work with ASP.NET nearly every day. It’s the primary platform we use at my day job, my startup’s main product uses it and I even spend a fair amount of my free time building sites in ASP.NET just for the fun of it. I think it’s a great platform. It’s not without its faults but I’m generally able to accomplish what I want or need to with it.
You would think with the amount of time I spend using ASP.NET that I would spend a fair amount of time at www.asp.net reading docs, getting support, helping others, learning more about the framework. But I’m almost never there. In fact, I think the only time I’ve visited recently is to download ASP.NET MVC. It was a decent resource years ago when I started seriously moving away from Classic ASP to ASP.NET but the site didn’t grow with me as I grew as a developer.
A lot has changed in web development in the past few years as well. There are a lot more web frameworks available, jQuery and other JavaScript frameworks have revolutionized client-side development and even ASP.NET has evolved, most notably with the release of the MVC framework.
The web itself has changed too. There’s a lot of value now in having your sites and services provide a social aspect to them. You’ve seen how compelling this type of thing can be if you take part in the vibrant community of .NET devs on Twitter. This is where the .NET community hangs out, shares ideas, argues about stuff and solves problems together.
Unfortunately www.asp.net hasn’t evolved along with the community it was intended to support and the current state of affairs on the web. I thought to myself, “How would you build www.asp.net if you could start from scratch?” I decided to write a series of articles to answer that question. I’m breaking it up into four parts that will be posted throughout the week (links will be updated as each part is posted):
I do not claim to have all the answers. These are strong opinions, weakly held. I would love to get your feedback throughout the week so that when the series is over, it’s something Microsoft can point to and say, “This is what the community needs from us.” Don’t hesitate to chime in with your thoughts, especially if you disagree with me.
Part one will be posted Monday night or Tuesday morning. Subscribe to my RSS feed or follow me on Twitter to be notified as each part is posted.
I’m at the jQuery Conference in Cambridge, MA this weekend. Today was day one of two and it was a great start to the conference. Stephen Walther from the ASP.NET team at Microsoft gave a talk on building apps with ASP.NET and jQuery. The talk got very interesting when he mentioned that he was running unreleased bits from a recent internal build. There were two things that were previously unannounced that I found interesting.
The first thing Stephen demo’d was using the jQuery Validation plugin with MVC. It’s been publicized that Microsoft is planning to ship the Validation plug-in similar to how jQuery core is included. What hasn’t been shown publically (to my knowledge) were any code examples. The one that caught my eye the most was this snippet which was placed just under the opening <body> tag in the view (from memory, exact syntax may vary):
<% Html.EnableClientValidation(); %>
After the talk Stephen let me view source on the outputted page. This helper method outputs the JSON structures needed for the validation plugin to work. Interestingly, it outputs them at the end of the page just before the closing body tag. Does this remind you of anything? Reminds me of Webforms. Declare something one place in your code and have it do things somewhere else. The other thing I don’t like about this syntax is the name of the method. I don’t think that’s a very descriptive term for what it’s actually doing. I’m working on limited information here though so it might be doing more than just outputting the JSON data. It’s still only pre-Preview 2 and MVC 1 went through 5 previews and a couple RCs with lots of refinements along the way so it could very well change.
The second interesting thing that was discussed was a change in the way GET requests for JSON are going to be handled. The reasons for this have been covered extensively. If you want to allow JSON to be returned via a GET request, you’re going to have to be more explicit about it before you risk shooting yourself in the foot. While the sentiment behind the decision is good, I’m not a fan of the current way you have to specify it (again, from memory):
public ActionResult GetJson() {
return new JsonResult(data, JavascriptBehavior.AllowGet);
}
What I deduce from this is that by default JsonResult won’t return data if the request is a GET without explicitly allowing it. This change would break existing code since it would need to be updated to allow the GETs. If the default is going to be changed though, why add the parameter? Why not just check to make sure the proper AcceptVerbs attribute values are present? Again it’s early and could change even before the next preview, but it’s a curious change.
From my experience it’s rare when MS demos something at a conference that wasn’t already covered in some other form (usually blog posts) so it was an exciting afternoon to get a little advance preview of the changes coming in MVC 2. Even though these two features aren’t implemented the way I would like, the MVC team has proven that they’re listening to feedback and willing to make changes along the way if better ideas are presented. That sort of openness into the process is reassuring and I’m appreciative of the team’s efforts.
Tomorrow there will be an open spaces meeting for ASP.NET folks that use jQuery. I’m looking forward to sharing some ideas and helping some others out if they have any questions that I can answer. If anything interesting comes out of it, I’ll be sure to pass it on. Also, be sure to follow me on Twitter if you’re interested in my thoughts as the conference goes on tomorrow.
