The Channel 9 beta has been updated...

I know you've heard it before, but we are heading down the final path to ship.... really we are

As part of that path, we've been working hard for the past few months focused on making sure that our new code base meets the expectations of you folk, the Niners. What has that meant? Well, it meant new features of course, but it also meant extending some
of our existing code to make it more enjoyable for how people use Channel 9... even modifying our initial ideas around the UI and the UX to make it both an improvement and familiar.

That is probably already enough talk for most people, so for all of those folks ... please feel free to jump over to the beta (http://beta.channel9.msdn.com), check it out, and provide feedback.

I do want to explain what is new/improved, what is missing and what are known beta issues that we are planning to fix in the short term. We'll go through these features/differences in an upcoming dev diary, but for now here it is in basic text form.

What's New/Improved

Browser/Standards compatibility

Nearly identical experience across IE and FF and the site is very usable in Opera and Safari

Font scaling (make your text size larger/smaller in your browser and the site stays usable and looking good) is now possible

Videos

Support for multiple video and audio formats (MP4, Zune formatted WMV, High Quality WMV, Regular WMV, WMA and MP3) with corresponding RSS feeds for use with aggregators including Zune and iTunes

Silverlight Player with an available iFrame for inclusion in other web sites

The ability to tell people about your favorite videos using a direct post to Facebook, Digg or Deli.cio.us link

Forums/Commenting

Asynchronous (AJAX) paging through comments on videos, threads in the forums and more

New "Reply To" model that automatically displays the comment you are replying to hooked up to your comment

New Editor with broad browser support

User Submitted content (wiki/sandbox)

Added commenting to wiki pages

Async history browsing and editing

New syntax matching codeplex's wiki syntax

Tagging support added to the Sandbox, so that uploaded samples can be categorized (think C#, Web, WPF)

What's Missing/Coming Soon

"Recent Changes" pages/feeds in the wiki are no longer available (will return)

"Compare with previous" no longer available (will return)

IE 6 support has issues, mostly around our extensive use of transparent PNGs

Profiles are really lacking compared to how they are in the current C9 (some improvements planned, will plan more based on your feedback!).

Watched Threads is gone.

User info (blog, web site, caption) on posts is gone, but will come back later in some form of quick info pop-up.

No Emoticons in the editor (coming soon)

No Poll

No Quote option for replying

Note: The beta itself is missing some things just because it is a beta, including Live ID sign-in... and our data isn't anywhere near up-to-date between the live and beta sites.

I'm sure there is more, but please check it out now and let us know what you think. There is a feedback forum (http://beta.channel9.msdn.com/forums/feedback) on the new site, but I've also created
a page for the beta on uservoice.com, you can check it out here
http://channel9.uservoice.com and you can use that site to submit comments, ideas, and to vote on other people's feedback.

I'm not sure about this async/AJAX forum loading thing. I imagine performance will get better when the new c9 is moved to the "real servers", but then I go over to on10 (where they've only got 2 pages of posts), which already appears to have async forum
loading, and I find the experience excruciatingly slow compared to today's Coffeehouse (at least most days). And even with better performance, I think seeing that progress animation makes it feel slower than it really is, especially when coming to the forum
page 1 from elsewhere.

Edit: Of course it doesn't help that the new forum page appears to be about 100KB not even counting the actual forum topic data, whereas the current c9 home page is about 35KB

the AJAX stuff is abit meh aswel.. say you go clicking past the thread view straight to an actual thread.. using the 'back' function in most browsers doesn't actually cache that last seen thread view content.. instead you gotta wait again for it to reget the
info again, its just stupid because.... like for another reason why is there no actual refresh button at the top of the forum thread views.. that just refreshes the thread content directly... instead of you having to refresh the whole page.. you'd think
the reason for adding this ajax syncing stuff was so that people weren't refreshing the whole page content and yet the one thing like adding an actual 'refresh' button isn't included.

maybe the AJAX stuff is good on your end hooked on nice fast connection directly to the db, but imho its just retarded and ofc no browser has yet to bring the user any real control of these pesky setups same with flash and even more so silverlight

and my favourite mouse gestures for going to next/previous pages the quick way doesn't work anymore either because of this retarded ajax page setup where there are no links that the plugin can look for like 'Next Page', 'Next', etc ...

I just posted this in the beta forums but I'll repeat it here:
I like the look, quoting should return, the avatars are still too small, and the add button should be disabled after it's clicked when making a post.

CannotResolveSymbol wrote:﻿Something about the site makes it so that you can't click any links at all in MobileSafari... I'll go fire up (desktop) Safari in a bit and see if I can't find any leads for you.

Thanks, I appreciate you putting the extra effort in to checking that... I have used the site from desktop safari, so I'm not sure if you'll see the same issue.

Yeah, I didn't see anything resembling the same problem in desktop safari.

It would be nice if Apple gave developers a MobileSafari emulation mode or something, where you could use the Web Inspector to get more information like you can in desktop Safari (when it works... seems to be broken on my computer). You don't have any transparent
<div>s hanging around that could cause this kind of thing, do you? That's what it seemed like (the page scrolled fine, the communities bar still worked, just none of the links on the page worked).

The site LOOKS great in Opera, but I can't click any of the buttons (new thread, reply, ...). Something weird is that each post has an EDIT and DELETE button. Does this mean everyone can edit and delete everyone else's posts Another thing I noticed:
when I'm at the Coffeehouse and I click on a thread, it loads the thread. When I click my browser's back-button, it goes back to the Coffeehouse, but reloads the content. This makes browsing the threads a lot slower.

Reset Password

We can't send you your password, but we can help you reset it.
Provide the email address you registered with and an email will be sent to your address with your new password.

System.NullReferenceException: Object reference not set to an instance of an object. at EvNet.Services.Emails.SendForgotPassword(EvNetUser User, String email) in
C:\projects\Dev\EvNet\Services\Emails.cs:line 93 at EvNet.Services.MembershipProvider.Users.ResetPassword(String EmailAddress) in C:\projects\Dev\EvNet\Services\MembershipProvider\Users.cs:line 760 at EvNet.Web.Pages.UserResetPassword.ResetButton_Click(Object
sender, EventArgs e) in C:\projects\Dev\EvNet\Web\Pages\UserResetPassword.cs:line 66

Yikes.

I got this when trying to reset my password. First I typed my email address and hit enter, after which the page posted back but nothing appeared to have happened. So then I clicked the 'reset password' button, and got this error.

I still don't know my account password, by the way. I always log in using my Live ID. Am I overlooking it or is it just not possible in the beta? Or do you actually need to create new accounts?

Edit: apparently not. I get an HTTP 500 error when clicking 'register'.

Reset Password

We can't send you your password, but we can help you reset it.
Provide the email address you registered with and an email will be sent to your address with your new password.

System.NullReferenceException: Object reference not set to an instance of an object. at EvNet.Services.Emails.SendForgotPassword(EvNetUser User, String email) in
C:\projects\Dev\EvNet\Services\Emails.cs:line 93 at EvNet.Services.MembershipProvider.Users.ResetPassword(String EmailAddress) in C:\projects\Dev\EvNet\Services\MembershipProvider\Users.cs:line 760 at EvNet.Web.Pages.UserResetPassword.ResetButton_Click(Object
sender, EventArgs e) in C:\projects\Dev\EvNet\Web\Pages\UserResetPassword.cs:line 66

So, did they forget to set CustomErrors="RemoteOnly", or was this in the interest of transparency?

Are you running Firebug? If so, you might want to try disabling it for these sites *or* (better option) updating to the most recent firebug beta... there is a bug in the release version that is causing some FF crashes, but I know that it was fixed in the beta.

steveo_, when we're done, the site will be faster. I don't understand your logic on how two requests has to be slower than one? In the case of one request the entire page has to be rendered before we send down any data to the client. Then when paging
to the next page of items, the entire page of data has to be rendered again and the entire thing sent to the client (again). With Ajax we're basically sending down a static page to begin with, with no items on it. This means less server processing and less
bytes sent down the wire to you. Then we do a request to send the raw data down (happening while the "shell" is still loading around it) and databind it on the client. When clicking to go to another page, the only thing we send down to the client again is
the raw data, so even more so than the first page load, we're saving even more server processing and even less bytes are sent across the wire this time. Current issues aside, what about that doesn't seem faster and more efficient to you?

If there are problems with history, let us know. That is a bug. Back/forward history support is already in there and works the same as if we weren't using Ajax. But again, if it's not, then we have a bug and will fix it.

Bug: by clicking "New Post" in the Sandbox and changing the forum to Coffeehouse, I can add attachments and tags to posts in the Coffeehouse, even though this is impossible from the form you get if you click "New Post" in the Coffeehouse.

Page Navigation

Bug: by clicking "New Post" in the Sandbox and changing the forum to Coffeehouse, I can add attachments and tags to posts in the Coffeehouse, even though this is impossible from the form you get if you click "New Post" in the Coffeehouse.

Good find, thanks!

EDIT: Did that post from the Wii so the formatting was goofy. Fixed now.

Are you running Firebug? If so, you might want to try disabling it for these sites *or* (better option) updating to the most recent firebug beta... there is a bug in the release version that is causing some FF crashes, but I know that it was fixed in the beta.

﻿steveo_, when we're done, the site will be faster. I don't understand your logic on how two requests has to be slower than one? In the case of one request the entire page has to be rendered before we send down any data to the client.
Then when paging to the next page of items, the entire page of data has to be rendered again and the entire thing sent to the client (again).

Nah, I know you think I haven't got a clue, but web developement is all I do..

I don't see how you cannot understand my logic of the two requests thing.. its simple, you may think sending one small fragment that essentially represents the master page, then getting a subsequent request to drag in the content is faster, but for the first
page.. its not.. its just a bad experience for the user who has to click the page, get a fragment appear, but then have to wait for the content (the content is what the user cares about).. the second request for content only happens once the first request
is complete, fired to the client, the page built up enough for dom to fire off the content request, the second request to complete, then get rendered out into the fragment area..

I'm not saying you can't use ajax, infact- this makes sense for paging, if I click page 2, then yea- update the content only, great idea, but its the first initial request that doesn't make sense to split.

﻿
I don't see how you cannot understand my logic of the two requests thing.. its simple, you may think sending one small fragment that essentially represents the master page, then getting a subsequent request to drag in the content is faster, but for the first
page.. its not..

There are 2 page requests, but what you're not getting is that the 1st page request is MUCH smaller that the 1 request of the current site.

And since the 1st page request is rendered PRIOR to making the 2nd request (safe assumption), you get something much sooner than you would get something in the current site.

So in that sense, it is a better experience.

The 2nd request should be as large as the 1 request of the current site, and depends on how much they pre-render the HTML, should appear just as fast.

So, if all things being equal, and things done right, V4 should be just as fast as V3... and probably more user-friendly.

Wouldn't it be a good idea to send both the page itself (or whatever is in that first request)
and the initial data (like the first page of a thread) in the first request, and then when someone starts paging, just do a request for the next page data? Then you'd at least get the first page in one go, and speedy data-only requests when paging.

HumanCompiler wrote:﻿steveo_, when we're done, the site will be faster. I don't understand your logic on how two requests has to be slower than one? In the case of one request the entire page has to be rendered before we send down any data to the client. Then when paging
to the next page of items, the entire page of data has to be rendered again and the entire thing sent to the client (again).

Nah, I know you think I haven't got a clue, but web developement is all I do..

I don't see how you cannot understand my logic of the two requests thing.. its simple, you may think sending one small fragment that essentially represents the master page, then getting a subsequent request to drag in the content is faster, but for the first
page.. its not.. its just a bad experience for the user who has to click the page, get a fragment appear, but then have to wait for the content (the content is what the user cares about).. the second request for content only happens once the first request
is complete, fired to the client, the page built up enough for dom to fire off the content request, the second request to complete, then get rendered out into the fragment area..

I'm not saying you can't use ajax, infact- this makes sense for paging, if I click page 2, then yea- update the content only, great idea, but its the first initial request that doesn't make sense to split.

I know you have a clue and I know all you do is web development. I've seen a lot of your tech posts. Maybe you don't know it's all I do too.

I get what you're saying about their being 2 requests instead of 1, but in reality for the entire page to load, there are a lot more than 2 requests. In the grand scheme of the page loading, that extra single request is minimal. As Minh pointed out (thanks,
Minh), the initial page load is much smaller and much faster. We could even set the cache for the page to be an hour so it always comes from your browser cache (since only the content is changing) to improve things further. I know most of the win here is
in paging subsequent pages, but there is still some performance to be had on the initial load.

As for the experience, I don't buy it. Look at any piece of software that gets its data from online somewhere. Would you rather the app not come up at all until it has the data or would you rather it come up and tell you it's loading data from elsewhere?
We still have some things to improve on the experience (no doubt), but personally, I'm all for enhancing the experience of the web and getting away from the jarring experience of page loads.

FYI, the homepage does load up the content with the page and then uses Ajax for paging. Per all of you complaining about the forum thread list (like for the Coffeehouse) loading up using Ajax, we already switched it over to loading from the server for the
initial load.

The reason it's slow right now (and this actually applied to Channel 8 too for those of you who commented on that) is that our production build has a problem at the moment and isn't crunching the Javascript. This makes for big files that also have their cachability
set to none. Once we fix the build problem the files will be much smaller and won't be downloaded on every single page request. Also, we've recently switched to a new webfarm for our new sites. Bigger SQL server, more web nodes, etc. We're actually just
running on 3 of the 5 nodes at the moment, but we'll go to 5 soon too. We will continue to improve the performance and experience, but we're definitely not leaving our current model.

Dev Diary videos are definitely going to continue, we just got too busy finishing/shipping the beta to publish anymore. Once we ship the beta to be the real site, we'll get back on the dev diary videos and talk about the entire platform.

Glad to hear it and you're welcome. We'll consider bold. No promises though.

As for when it will replace this one, we don't have an official date we can say, but we're looking for as much feedback as you guys can give and bugs you can find so that once we address all of those and the site is solid (read:bugs and performance tuning)
then we'll flip the switch.

So far we've already fixed some of the bugs you all have mentioned and appropriate other modifications. We are feature complete and will continue to fix things until we're comfortable you'll all have a good experience on the new site. We're getting close.

Also, to set everyone's expectations, we know there are some things missing at the moment (nothing major we hope though). Items that we here about the most from all of you will get back in faster. In the past we've been pretty slow to say...release
the beta, update the beta, etc. Now that all our sites are on the same code, iterating on all of them is a piece of cake and new features take a lot less time (now that we have the base platform done). We will now update the site as we get new features and
bug fixes. My guess would be that you'll see updates monthly, but the way Duncan likes to deploy as soon as we're done coding you'll probably sometimes see updates weekly. We just want you all to understand that we're much more agile now and will be updating
the site a lot more frequently.

its cool how the header background was done. Will be easier to make christmas themes etc.

would be great if we could make our own and add them to profile - and even share them

Cool backgrounds. I'll probably go over it in a future dev diary video, but basically we've redone how we do "theming". For us to create a new theme (or even you guys) is pretty trivial. I can't promise we'll get to user theming anytime soon (if ever), but
personally, it's a feature I'd like to see and again, now that we have the base platform there, it's not too hard to add.

My intended reply was to ask what browser/os you were using... because changing that check in Silverlight.js may not be enough to make Silverlight work in your browser... I was also curious if you had the ability to spoof your user-agent, and if Silverlight
on the site worked for you in that case?

Are you running Firebug? If so, you might want to try disabling it for these sites *or* (better option) updating to the most recent firebug beta... there is a bug in the release version that is causing some FF crashes, but I know that it was fixed in the beta.

I disabled Firebug, and i got past the sign-in page, but it crashed on the profile page.

I look forward to the new C9, but I don't really like the fact that it relies on JavaScript so much. Like you can see from the bug reports, browser-specific code creates a lot of problems. I realize it's too late to radically change the architecture of
the EvNet-platform, but I'd have prefered a site that uses progressive enhancements, where CSS and JavaScript are used to add dynamic functionality to an application that also works if CSS and/or JavaScript are disabled (or not implemented by the browser).

I look forward to the new C9, but I don't really like the fact that it relies on JavaScript so much. Like you can see from the bug reports, browser-specific code creates a lot of problems. I realize it's too late to radically change the
architecture of the EvNet-platform, but I'd have prefered a site that uses progressive enhancements, where CSS and JavaScript are used to add dynamic functionality to an application that also works if CSS and/or JavaScript are disabled (or not implemented
by the browser).

That is our preference as well, but we didn't start out with that in mind... which, as you probably know, is less than ideal

We are trying hard to make sure the site works without script for at least browsing... we aren't working on commenting/posting without script at the moment, but we'll probably get to it eventually.

As far as the browser specific problems goes, I don't think we are actually running into that many that are related to browser compatibility issues... and we have very little browser-specific code. The dev team is using FF 2.* and 3.0 beta 5 right now, along
with IE7 and IE8 ... and testing in Opera/Safari and as of a few days ago another Gecko browser K-Meleon ... all without any real issues. We are focusing on doing the CSS/Script correctly the first time, so that it works across all of these browsers without
having to do any hacks.

I understand the desire for progress enhancement, and you are right that it is too late to radically change the architecture of the UI, but we will be making the experience better for non-javascript supported and non-javascript enabled browsers over time.

BlackTigerIf you stumbled and fell down, it doesn't mean yet, that you're going in the wrong direction.

Just a quick note to let folks know that we feel
the beta is getting very close to ship... there are still a few issues that we know about, and probably many that we don't... so this would be a great time to head over, click around, sign-in, post comments, play videos... etc...

one known issue:

some videos have been accidentally tagged with wiki tags and therefore are showing up at the wrong urls (and not working) ... I believe this is only happening for a few videos in the Silverlight and WPF tags right now, and we're working on fixing it.

I'm sure there are others, but I'm tired and that is the one that I just noticed!

As far as the data is concerned, the wiki is out of date by about 2 weeks, but the rest of the site should only be a few hours behind. The data transfer is a process that I kick off manually though, so that few hours gap will increases while I sleep

Here's the thing: I still can't log in. There's no Live ID sign in that I can see, and I still have no idea what my account password is. I tried the reset password feature, but that throws me this error:

System.NullReferenceException: Object reference not set to an instance of an object. at EvNet.Services.Emails.SendForgotPassword(EvNetUser User, String email) in C:\projects\Dev\EvNet\Services\Emails.cs:line 93 at EvNet.Services.MembershipProvider.Users.ResetPassword(String
EmailAddress) in C:\projects\Dev\EvNet\Services\MembershipProvider\Users.cs:line 725 at EvNet.Web.Pages.UserResetPassword.ResetButton_Click(Object sender, EventArgs e) in C:\projects\Dev\EvNet\Web\Pages\UserResetPassword.cs:line 66

It's not obvious how you go to the last post of a thread. If you click on the username, you get rightly whisked to the user's page, so maybe hyperlinking "Last:" with an anchor to the last post?

We don't have a "last" link anymore. That's why it's not obvious. We ended up not having time to implement it before launch (but it will come soon after probably), but we're going to do something more useful, which is to automatically take you to the
last unread post when you enter a thread (with no page parameter specified). "last" doesn't always get you where you need to go, just on the right page. We can do better (and will soon).

﻿Bas, true...sorry about that. We just fixed (today) some more interesting problems with passwords and resetting them. When was the last time you tried to reset your password?

Yesterday afternoon. I'm gonna give it a go right now...

...hmm, it now says that my new password has been sent, but I have yet to see it appear in my inbox. I hope I used the same e-mail address to register my account that I use for my Live ID, otherwise I have no idea which one to use. Maybe it'll arrive later
on.

(Edit: hmm, looks like it just tells you that the password has been sent regardless of what you enter in the e-mail address box.)

Minor nitpick though: The "Your new password has been sent" message could be a bit clearer. Right now it's the same text you got before clicking the button, just with the "Your new password has been sent" message tacked on. It's not immediately clear that something
has actually happened.

stevo_ wrote:

﻿

HumanCompiler wrote:﻿Bas, true...sorry about that. We just fixed (today) some more interesting problems with passwords and resetting them. When was the last time you tried to reset your password?

Sums up the vision of MS when it comes to the web, your mighty interested in it, but aren't following any of the passion that generic web developers have..

Adding a noscript tag to at least tell the user whats going on isn't a big deal..

If your adding experience that utterly required js, then you shouldn't leave the non-js people in the dark.

I would actually agree that adding features shouldn't be done unless their needed.. but adding a noscript tag is a 30 second job, to say 'yea- we thought about you guys.'..

I guess you have a point about the non-js experience, but what does that have to do with password resets?

HumanCompiler wrote:﻿Bas, true...sorry about that. We just fixed (today) some more interesting problems with passwords and resetting them. When was the last time you tried to reset your password?

Sums up the vision of MS when it comes to the web, your mighty interested in it, but aren't following any of the passion that generic web developers have..

Adding a noscript tag to at least tell the user whats going on isn't a big deal..

If your adding experience that utterly required js, then you shouldn't leave the non-js people in the dark.

I would actually agree that adding features shouldn't be done unless their needed.. but adding a noscript tag is a 30 second job, to say 'yea- we thought about you guys.'..

You shouldn't over-generalize. We're a big company. We're a very small team and have limited time. Our focus is on the best experience for the most amount of people for the least amount of development time. We'll continue to work on the no javascript experience,
but our only priority there is for search engines. We don't get a whole lot of users to our sites that don't run a javascript-capable browser. As usual, I'm missing what the big deal is here.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.