Erik Porter

We do follow the "it's the web" mentallity EXCEPT for Linux.  We have nothing against Linux here on the C9 team we just don't get many viewers from Linux and therefore don't spend much (read: any at the moment) time on it.  Everything "should" work on Linux Firefox the same as it does on Windows Firefox, unless our browser detection code isn't working.  Please go here and paste in what comes up on this page: https://channel9.msdn.com/browserinfo.aspx.  Thanks!

Bas, I'm not sure our background services are turned on right now and that's what sends out the e-mails.  We'll get back to you tomorrow.

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.'..

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.

PaoloM wrote:

One more thing to fit in the schedule!

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). 

acnvrk, interesting idea.  There's more we'd like to do in the future with the RSS feed.  We'll consider your suggestion.  Thanks!

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?

stevo_, you CAN or you DO?  I don't think we need to make any changes for what CAN happen.  If we are crippling a lot of our users that'll definitely get us to make changes.

jamie wrote:

 

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. 

jamie wrote:

well regardless of that - or the editor - im looking forward to it (and something new to look at)

when will it replace this one?


PS - the flyouts look better with lowercase text.  thanks for that
...although..consider bold (like now)  ?

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.

Minh wrote:



KevinB wrote:  Minh wrote:  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. But aren't you ignoring that the fact that to complete two requests may take longer than 1 large request when you begin to include latency issues?

Relatively, it doesn't matter. Because you only make the 2 requests at the beginning. When you start doing paging, you only make the data request (at least you should).

And since you don't get the browser "flash", it is a better user experience.

But that is all dependant on the entire thing not being noticeably slower than the current site.

KevinB wrote:  This isn't a critcism of the design, I quite like it, but I have always felt that the perceived speed of Channel 8 has always been slower than Channel9.

I defintely felt C8 is slower... and if C8 is running on the same server farm as C9, then, Houston, we have a problem... Come to think of it, C8 is almost certainly on the same server farm.

Hmmm...

Thanks for the comments, Minh.  Appreciated!

As for C8 being slower, see my previous post.

KevinB wrote:



Minh wrote:  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.

But aren't you ignoring that the fact that to complete two requests may take longer than 1 large request when you begin to include latency issues?

This isn't a critcism of the design, I quite like it, but I have always felt that the perceived speed of Channel 8 has always been slower than Channel9.

However, the many advantages of the new C9 outweigh any potential speed issues that the new site might have when it is launched.

Kevin

P.S. Congrats on the new design by the way, it is a massive improvement, can't wait until it launches.

Do you have any plans to do more of those Dev Diary videos, they were good.

See my previous post about Channel 8 (and Channel 9 beta) performance.

We're glad you like what you see...thanks! 

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.

stevo_ wrote:



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.