Unfortunately I gave you some misinformation: you can change the article type, but only when posting a regular article. You've posted an alternative to an existing article, meaning that your alternative must be the same type as the original article. An alternative to an article is an article, an alternative to a tip is a tip, etc.
Starting today, the "Vote to remove this message" link in forum message won't simply add to the tally of votes to decide if a message should be removed: Abusive or innappropriate messages now lose their authors 20 points. Next week that increase to 20 points x member level, meaning a potential loss of 200 points per message flag.
Previously our article URLs were of the form www.codeproject.com/kb/section/basename.aspx. This worked well and allowed you to easily remember your own articles. My grid control article, for instance, MFC Grid control 2.27, was an easy URL for me to remember.
The issue was that while this naming convention was simple, it was also predicated on each article within a section having a unique basename. With 35,000 articles, this was starting to become a little tricky.
On an unrelated, but nevertheless important note, we strive to ensure our authors' articles are positioned as high as possible within search engine rankings. Search engine ranking depends on an enormous number of variables, up to and including the phase of the moon, but while "http://www.codeproject.com/kb/miscctrl/gridctrl.aspx" is OK, "http://www.codeproject.com/Articles/8/MFC-Grid-control-2-27" is better. And "http://www.codeproject.com/Articles/317712/An-MFC-Chart-Control-with-Enhanced-User-Interface" is even better (from a search engine point of view) than "http://www.codeproject.com/kb/Chart/MFC-Chart.aspx".
And as a final but neat freebie, we have tossed the extension. No more .aspx. A trivial thing, but when Microsoft comes out with the Next Big Thing, or we move to PHP or JSP, then article links will be the same. This should be the last URL change we ever have to do for our articles.
1. Completely revamping the article submission (for everthing) and the display system for tips. 2. Adding new options for articles. 3. A ton of work on Lake Quincy. Our little project is all grown up and has an appetite for developers to match. 4. Machinations and experiments with Quick Answers and the Forums. Some very interesting stuff. The most interesting bit is making it so you guys don't notice anything until there's the "oh - I see!" moment.
Some devs like to make big splashes. I prefer my code to just settle in comfortably into your lives and work without you realising anything.
The upshot of this is that I have zero social life and even less time to hang out in the Lounge. Bah humbug.
One of the features that has generated a lot of debate and suggestions is the way we handle text, HTML and code in the forums. Copying and pasting code - especially web related code - into the message editor can cause problems due to the unintentional posting of HTML tags instead of HTML encoded content.
To help with this we had "When Pasting" options at the bottom of the message posting area that allow you to set defaults on what happens when you paste, but what you want to do changes depending on what you paste. The problem here is that you defaults don't always fit the situation at hand, so we need a way to allow you to change your mind easily.
From today we removed the paste options from below the message and instead show a popup dialog that intercepts the pasted content and tries to figure out what your options are with visual aids to help show what each option will do. The "When pasting" that apply to the paste text are shown in this dialog, and as you hover over each option the pasted text in the message text area is updated, as well as a small preview in the paste dialog to give you a quick peek into what it will look like. If you are pasting text that will look the same whether you're pasting as text or HTML (or mixed) then the options shown are reduced to the minimum set possible, and your default setting will be automatically checked and always shown.
On top of this, as you type, a preview of what your message will look like is now shown at the bottom of the page.
If, after pasting, you are happy with what's shown, or don't want to be bothered, keep typing. The dialog will fade away. This is not the popup dialog you are searching for...
The changes are designed not to simply show you what will happen, but also to give you an ida on how to encode your content to ensure it displays in the manner you intend. The changes are also meant to be as unobtrusive as possible, and text will be pasted initially as per your defaults. We're only adding a simple way to change your mind.
For those who never pick a default, and never touch the popup dialog, the default will always be "Best guess" meaning if it detects code in the pasted text it will wrap in PRE tags, otherwise it will paste and preserve HTML tags (no encoding on paste).
Encode button in the editor
We spared no expense in adding an "encode" button. Highlight some HTML, hit encode, and the text is HTML encoded.
Editor Live preview
Hopefully you waon't even notice (unless it's in a good way) but more content is being pre-cached, speeding up some of our lesser-used pages.
Split Quick Answers / Discussions menus
More admin options
We've armed ourselves with some bigger guns to deal with reported items. Don't worry, this won't hurt a bit.
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?