The forum indicator lines were a small HTML5 experiment I was doing that turned out to be actually useful. The quick version is: when you hover over a message, find that message's parent (if it's on the page), create 2 canvases representing the two segments of the line, and draw. If the parent message isn't on the page, show an arrow tip indicating "over there somewhere". Why not a single canvas? Because IE doesn't support the pointer-events:none style. pointer-events:none allows you to have an element on top of another element (say, a single canvas overlaying the forum) and have that element ignore all pointer (eg mouse) events and instead have those events pass to the underlying controls.
The way around this was to create two canvases that didn't overlap anything mouseable, with a nice byproduct being a healthy speed increase (smaller canvas = faster resizing, repositioning and drawing)
The forum flags in the bugs and suggestions[^] forum (and soon, your article forums) allows me to provide a simple visual feedback on the bugs and suggestions posted. If you find a bug you can scan the page, find a similar (or same) post, and note that it's in progress to being fixed or that it's fixed and will be released next deploy.
The new forum message posting page now incorporates the same editor that's used in Quick Answers. For me this means a single codebase to maintain (yay!). For you it means the auto-code sniffer is now in the forums (yay!). Post some code, the sniffer will try to see if it's code, and if it is it will wrap your pasted code in PRE blocks and assign the language automatically.
Site speed continues to be a focus and we've put in a ton of work to improve caching. Our main database was cruising along at 75% utilisation at peak times and that's bad in anyone's book. We're now down to about 50% simply by tackling the easy jobs, and with a further push to do some fundamental re-architecting, we should again halve that. For the first time in our history we're no longer looking to add database capacity, but are actually now consolidating databases and saving ourselves some SQL licencing fees.
Optimisations to improve site speed have been done on a number of fronts, from simple caching, to the best optimisation of all: not doing the work. An example is our Quick Answers[^] homepage. Previously we were tracking which questions you had viewed and which you hadn't. It turns out there's an excellent technology in place that can do this for us: your browser. You view a link, the link is purple. Why should we override that and add functionality already in place?
Another example is when viewing a question you see the Next / Prev links. Calculating which message is next and previous, based on your interests, the current message, your filters and the waxing or waning of the moon is expensive, yet only a fraction of members will actually click that "Next" link. Those who click it, need it and love it, so the answer isn't to remove it. Instead of calculating the "Next" question on the page that shows you the initial question, we initially have the next button go to a fixed page that will do a single expensive query for you, and then cache a large number of questions in either direction.
Previously when viewing the question you had the hit of calculating the next question. Now, no hit on viewing the initial question, but a small hit when you first click Next. After that the results are cached, and there will be no further delay until you exhaust the cached results.
Plenty new features are simmering away. I'll try to provide more frequent updates.
The indicator lines in forums have been turned off for now after a user reported it was causing Chrome to lock up. I'll dig in and find the cause - or at least find a workaround - and get them back ASAP.
The real reason is that way, way back, I was using red to highlight "hot threads". It was all very hip and '90's. However, for the past hundred years or so we've been using red to denote popular and up-voted items, not "hot" threads (in the sense of "lots of action" instead of just popular). We also use green to denote good answer and red to denote bad answer so it was blatantly inconsistent.
There have been a couple of complaints regarding article moderation.
1. I want rep points
2. Having a single member be able to give the green light to an article is dangerous.
The new reporting system solves these problems by
1. Giving rep points
2. Requiring 5 members to approve an article before it goes live.
Each time you are presented with an article that asks for moderation, hover over the 'tick' box, choose whether to approve or report it, and your vote is entered and the number of current votes on the article are then shown. When it hits 5 votes then the article is approved or closed, depending on the majority of the votes.
If an article is closed but then reoponed by the author or an editor then the reports are wiped from the article, but points accrued from the previous reports stay.
So please: approve and report. Let's keep things organised!
If an article is closed but then reoponed by the author or an editor then the reports are wiped from the article
Can you explain this part a little?
I see, if we report someone for formatting and content, we get points for that. Then, Author modifies and updates the article. Now, when we approve it, we do not get the points. Is it ok? As designed? Shouldn't one get points later too once the aricle was updated?
Previously when reporting articles or questions you would click the little red flag and fill in the form on the following page. Sean, myself, or one of the editors would then review the report and take action. Almost uniformly the reports were "Total rubbish article - please remove", or "Spam".
This was tedious for us and opaque for you, so we've revamped the reporting system so that reporting articles and questions (and tips and blogs and answers) is done via Ajax (no page refresh) with the reports now collated automatically. When enough members have reported, the item will be closed and the reason for the item being closed will be displayed, along with those who reported the item.
This last part will cause, I think, the most debate but reporting is limited to Silver members and above and with everyone seeing what everyone else is reporting, anonymous report wars will be that much harder to instigate.
Reporters also get Organiser points for doing their civic duty.
So: if something is truly awful report it. If a question is posted and the author has made no attempt to help others answer his question, report it. It takes two seconds and will help promote the best content, the most well posed questions.
One final feature is that if you yourself find your article has been reported and closed then you have the ability to re-open it by simply editing and updating your article. You always get a second chance, but you will need to make major changes in order to reopen an article, and please be aware that if you open an article and it's reclosed then there's a good chance it will simply be deleted.
If your article or post (or answer) is closed and you think the closing was unfair, email us and we'll investigate and reopen if necessary.
I still owe everyone a write up of our move to a new hosting centre, but I thought I'd just mention a little bit of trivia: until this morning we were still running 3 servers on Windows 2003 R2. I know - that's so 2005, but they worked. Well, mostly.
IIS6 was a phenomenal improvement on IIS 5 and we saw impressive stability and perf improvements. However, the pipeline model was annoying because ASP.NET was tacked on to the web server instead of being treated as a first class citizen, so doing things like handling non-.aspx files in ASP.NET was needlessly cumbersome.
To this end we were using an old, old component that Dundas Software was giving away, called Filter Plus. We modified the code a little to suit our needs, but it was a simple ISAPI filter that would take a simple config file and use the patterns in that file to tell it how to reroute requests. We were able to take all requests for all /kb/<section>/filename.aspx pages, for instance, and map them to a single page that would load and display articles (and incorporate some handy caching). Essentially it was a url rewriting component long before ASP.NET url rewriting was a twinkle in ScottGu's eye.
This worked exceptionally well, thanks to the coding of Troy Marchand, the original author, and allowed us to handle zips and images and all sorts of fun, but it involved extra settings, an ISAPI filter, and some if..then's in our code for servers that were't using this filter.
Win2008 / IIS7 made all this redundant and cleaned up our code nicely, and from today on I can remove the if...then's and move on to an IIS7+ model only.
We'll miss web18, 19 and 20, but web2 will handle all their duties, and more, and on a single machine.
So we're down to 4 servers: web2, 22, 23 and 24 and are serving pages faster than ever with better uptime. We have also moved from 3 database servers to 2, and can easily move to just a single database server but find it nicer to be able to have the failover option along with plenty of headroom. Servers - and I mean, big, serious iron - have become astoundingly cheap (relatively) - and the multi-core offerings provide amazing performance.
We've also moved our email systems to a hosted provider in a move that was a long time coming. No more worrying about my insanely large mailbox, no more patching and managing exchange, no more backups. The less we need to worry about servers and SysAdmin the more we can focus on doing what we do best.
A few more updates to the aging UI have been released so I thought it worth walking through a few of them and providing a little rationale.
First, the homepage is, clearly, a little different. While the old page had high information density, it was so high as to be approaching noise. I always thought of the homepage as a newspaper front page - lots of boxes with lots of info all available at a glance. That's great when you know what you're looking for, but terrible if you are casual cruising or if you just want to quickly scan a page and quickly look through what's new.
And that's what most homepage readers do: see what's new and move on.
So the design of the homepage was done to allow someone to take a quick peek at the homepage, see what's new, what's interesting, and then get on with it. There is still a little tweaking to do in terms of the actual data shown, but the layout itself is as it will be.
You may have also noticed that I've removed the sidebar on many of the pages. My idea with this, way back when, was that readers would come to the homepage, diligently read the entire page, then peruse the list of chapters and sections and (diligently) work their way through the article.
Except that everyone just hits Google and then goes directly to the article they need.
So, instead of the sidebar navbar we now have a simple link to the main Site map, and we also have a fly-out sitemap under the "Article" menu. Removing the sidebar gives us two benefits: vastly reduced page size (and quicker download/page render) and more screen space. The homepage is now around 18K vs 77K (give or take) which means a lot when you're mobile or on a slow connection. Further speed increases are coming.
I've also added visual hints in the top scrollbar showing where you are in relation to the nav bar navigation. A small thing but a useful thing.
The survey has been moved from the bottom to the side. While the surveys are not exactly the most scientific of research (let's be honest - Sunday night and a bottle of red and hey presto! A new poll) they are hugely interesting, but they were buried. Just watching the partipation rate this week showed the move has been good for the polls.
There is also a nice bonus for those who feel advertising is the root of all evil in this world. I've removed two ads from the homepage and replaced with a smaller box ad. I, personally, always read our ads because I always see stuff potentially interesting (a requirement for any ad we run). However, I'd rather have a cleaner layout than advertising any day, so I fired one of them.
One non-UI addition is that sign-in and profile update is now all done via SSL. I know this won't help issues with packet sniffing over unsecured Wifi networks, but what it will do is protect your passwords. People hate thinking up and remembering passwords so there is a ton of password reuse. By keeping the passwords out of the hands of miscreants, and hashing, not encrypting, passwords, we can do our bit keep your private business your own.
There are also a few smaller touches around the place. A little shading and shadowing, highlighting of the currently focused text box, a small tweak to colours but nothing that, I hope, will cause tempers to flair.
The point of all of this is the old maxim in editing: remove half of what you write; then remove half again.
While I will never claim to be a designer I can claim to be a user, so my focus is on making the UI work for me, and for the majority of those who use the site. While this will never make 100% of the users happy, creativity can certainly help me bridge that last little gap.
All in all: 26 or so extra pixels of screen space recovered. As an added bonus about a dozen minor but annoying bugs have been squashed.
Now - who will be the first to complain about the lounge link?
Nothing really huge, more of just a recognition that voting for a question or answer is different than voting for an article.
Voting is incredibly important in helping filter the good and the bad, but useless if no one votes. Voting can be, however, detrimental to the motivation of authors if downvoting can take place without accountability.
My feeling on this is that articles, technical blogs and Tips are permanent references and their vote has weight. Questions are ephemeral and nowhere near the amount of effort has gone into posting a question as would go into, say, posting a tip - let alone an article.
In light of this I've removed the features for questions and answers that requires a comment to be provided on a downvote. With the introduction of the comment requirement the number of votes fell dramatically, and the votes that did occur were not always useful. By removing the barrier to voting, Quick Answers now falls into line with the discussion forums with voting now easier and more likely to be cast.
We'll see. Maybe this is a Very Bad Thing. Maybe we put comments back on answers, but not questions. Maybe we change the voting to simply be yay/nay.
It is good thing to keep Voting for the answer , also there should be some way where the question poster once he gets the answer he should vote appropriately , not only take use og the forum answer, I want to add some more points to the quick answer section, most of the people are posting thier comments as answers this not correct as posting comment will get one point and posting answer 10 points
After an absolute marathon 3 weeks I'm happy to let our new baby free into the world. A cleaner layout, less clutter, no more left-hand side bar, and a rationalised top-menu.
While doing this we also added a few more things:
- inline posting of answers in the Quick Answers section
- Next / previous buttons on Quick Answer pages to allow you to whiz through them faster.
- Source code browsing
- A flyout sitemap of Chapters and sections (see the sign post at the top left of articles)
- A slightly (and I mean, slightly) improved iPhone experience.
- A few niceties for non-IE users, and a couple more on top of that for Opera and Chrome users.
- 'Learning Zones' - areas where we will bring together content on a given topic for new (and advanced) members
- You can add your Twitter name to your account to give a little exposure to your twitter feed.
There are definitely a few little surprises around. I had to be brutal in removing unnecessary stuff and even now I still want to remove 50% more.
There will be a period of weirdness where the site is half-in, half-out of the new design, but I wanted to at least push forward with the article design since that brings the biggest benefit to the majority of our readers who simply come here for a 5 second quick fix.
One of the obvious ways to make something faster is to give it less to do (excepting, of course, that well known adage that if you want something done, give the task to a busy person). Caching is the prime method of speeding up a website and takes many forms: SQL server caches results, your data layer may cache results, your business objects may be cached, ASP.NET has a cache object, Appliction and Context objects, the session object, disk caching, your user controls and pages have output caching, there is server side caching within IIS, partial page caching, and client side caching within your browser itself.
Just to name a few.
Unfortunately your web.config file doesn't have an entry <caching level="11" for="everythingIncludingTheKitchenSink" />
Setting up caching requires attention to detail and an understanding of where the load is best relieved, what type of data synchronisation issues you may have (working in a webfarm?), what member you have, the length of time you wish to cache and your caching resources (memory).
For the last couple of weeks we've been focusing on the client side trying to understand what is causing the page to download slowly, and what we can do to speed up rendering. To this end the obvious fixes were to ensure IIS caching was enabled, and not just enabled, but enabled correctly.
IIS caching requires you to explicitly tell IIS that you want caching. Because, you know, you might enjoy having your readers download those images every...single...time. So you turn it on - ensuring you enable it for both static and dynamic content - and you find it works for your IIS6 servers but not your IIS7 servers (yes, we mix and match. We're crazy like that).
The trick is removing the eTag. Do a search and you will find the trick is actually setting the eTag changenumber to 0, which requires downloading the IIS Metabase editor, cranking it up, adding an arcane key and crossing your fingers. This then ensures that the eTag, a value that should be the same for a given version of a file on all servers, is the same. Change the file, the eTag changes, and the file is re-downloaded by the client and cached until it next changes.
However, the eTags between IIS6 and IIS7 differ so the only way to get around this is remove the eTags. An eTag is just an HTTP header so in IIS6 you just manually ask IIS6 to add a new header to the output stream called "eTag" with the value "". Voila, no eTags.
Except that this doesn't work for IIS7. People say it does, but it doesn't. You'll need to write a HttpModule to strip the output of the eTag manually.
You now have caching working. You've enabled it, set the expiry as a date in the far, far future, removed eTags if required, ensures static and dynamic are cached, and all is good. Speed skyrockets. Well, perceived speed.
However, you still have many readers who come once, and once only. Caching is no use for them. So the next step is compression.
Compressing your downloads (zips, images, HTML content itself) is again set by IIS but it's, yet again, a PITA in IIS6. I'm not going to go through the details - just do a search for "IIS compression metabase.xml" and you'll find the instructions for enabling compression properly on your servers.
And again you now have compression. You're sending small packages downstream, sending them less often, saving bandwidth, saving processor time, and everyone wins.
Just make sure you make copious notes of what you did, because when it comes time to adding a new server or repairing a failed server, you really don't want to go hunting around for all this stuff again.
Now where is that web.config setting we all need...
1. The trees start turning in Quebec mid-August. This, to me, is totally unacceptable until a mate pointed out that we could have our first snow within 8 weeks. It's currently so hot outside the tarmac is sticky.
2. Raccoon poo can burn wood
3. I have a dray of squirrels going ballistic in our trees and a gaze of raccoons treating our roof like a trampoline that opens at 5am. Gaze and Dray - your words of the day.