Re: Anonymous Coward no more ?
We had a huge hiccup, sorry - the setting was mistakenly only available to NON-logged in user. The problem has now been rectified.
201 posts • joined 3 Dec 2012
I strongly recommend using a bookmark instead of typing URLs manually, and/or inding ways to remove the bad URL from your browser's search box if it comes up: doing both should help making https://www.theregister.co.uk/Week/ rise up to the top of the items shown when you start inputting "www.thereg" in the location bar, assuming you've "hit" /Week/ enough times.
I'll be able to have a look at this in a couple days, but I don't think there should be any problems with us adding an additional 404 redirect for /week and /week/ to /Week/. Look back in a couple days!
replies don't appear after submitting unless I reload the page; then they pop in.
Assuming you're talking about comment replies... it's just the way things are: when you submit your reply it's accepted and stored for later processing; it _can_ just so happen that if your comment is auto-approved and the processing queue is clear and the time it takes for your browser to redirect you to the forum page takes long enough, you'll see your new comment "there"; but it may as well happen that the queue is busy (or down for maintenance) and it'll then take longer. I believe the message shown after each reply makes mention of this.
I've had JS turned off for aeons & not had this problem, so why it suddenly starts now is a mystery.
We used to have a form for each upvote and downvote button, and that's a "form" tag and a "button" for each arrow for each post. As we're now showing many more posts per forum page, we needed to find ways to reduce the amount of markup per page, to keep the amount of bytes sent and amount of DOM elements the browser has to deal with lower.
To do that, we've switched each of those "form and button" to a link, which halves the amount of DOM elements (and quite a few bytes!) for each post.
Behaviour wise, both perform an AJAX request if you have JS disabled.
Unfortunately for JS-disabled users, the link requires you to go through an additional step to up/downvote. As this is an ad-supported site, which stays afloat due to ads, and since ads are delivered via JS... there's only so much we can do towards supporting JS disabled users, and we've got to draw the line somewhere.
I can click on the number to Up/Down vote, but there's nothing prior to either number to indicate that they ARE for Up & Down voting. No button, no text, no AltText, nada
The "a" tag for up and downvotes has a "title" attribute ("alt" is for images), which should be read by screen readers. NVDA does find it and read it (if I tab through to it). I'm not sure why JAWS19 doesn't do that, but there's only so much testing I can do... What I've bet on so far is that if we provide semantic and meaningful markup, screen readers ought to work well.
What happens when the replies get deep enough?
The amount of left padding between posts decreases, "harmonically" (taking logarithmically less space) until a point at which all replies are shown at the same level. The point varies by breakpoint: 40th child on 884px+ wide devices; 30th for 700px+ devices, etc. all the way to just 6 replies for devices less wide than 380px.
There are quite a few (mostly old) forums with very deep replies, which have been tested :)
While there is a theoretical limit for how many replies this system can truly support the nesting for, it's high enough to not be a problem anytime soon ;)
There used to be buttons to Up/Down vote a comment.
They're now simple "a" tags instead of a complex form with a button, so we can have less markup to deliver pretty much the same thing, to the detriment only of no-js users, who instead have to go through one more hoop to find the html form to upvote (sorry, but the site runs on ads and ads require js!)
They no longer get read by my screen reader.
My (admittedly limited, being sighted) testing with the accessibility inspector and with NVDA on Windows (which I'm using more often in recent months) shows me that tabbing through the links on the page the "new up/downvote links" get read as "NNN link Like this post? Vote for it!" or "MMM link Dislike this post? Vote it down!" with NNN being the number of upvotes, MMM the number of downvotes. I'm not sure how or why your screen reader isn't showing you them. They're links, and can be tabbed to :/
clicking the numbers to vote spits me back to the top of the page & loses my place in the comments thread
Now, this is something that doesn't seem right in the slightest. Our client-side guru is aware of this and will be looking into it (likely Monday, as it's about beer o'clock...).
Re IPv6, "soon®". There's many backend bits we have to clean up before being able to turn it on for the main site. Meanwhile, IPv6 for places we could enable it at the flick of a button already have it enabled, like our image hosting domain, regmedia.co.uk... so not all hope is lost - it's "only" the main content site that lacks IPv6.
The rest is IMVHO as easy to enable as it's hard to recover from if we (or others!) fuck it up - while at the same time not providing as many tangible benefits to either us or users as, say, having https "on" and "default".
Considering that the (admittedly few) bank sites I've tried also get an F on that report, I'm in no rush either...
Comments (and replies) don't appear for me after posting unless I reload the entire page.
Could you clarify what you're expecting should happen, and doesn't?
After you post, you're shown the forum page with whichever comments are live at the time the page is shown. It may or may not show your just-posted post or reply, depending on the quickness of things.. but it won't self-refresh and show you new posts unless you refresh the page.
Beware though that if the page contains a URL fragment (i.e. #c_NNNN in the URL, which we might use after a reply POST in order to point the page view at the point of the reply) the browser will not request the page again unless asked to "hard refresh" the page. That is, CTRL+L and Enter will not refresh anything, whereas CTRL+R will.
Hope this helps!
Has anything changed in the last 2 days?
Yes, indeed: we got rid of the forums RHS "your topics" unit and we've reshuffled the top RHS forum unit. The information is still available at the "My Topics" link.
As a part of that change, we've removed a couple mostly useless queries which were instead done at every "forums" page load. Most pages are a bit faster to be delivered to you.
A byproduct of that change was that an internal variable, which used to be available on every page due to it being set in order to produce the list of "your topics" to be displayed on the RHS, was no longer being set in that way; and the forum backend erroneously used that variable to figure out the list of posts in that forum you had up/downvoted.
I've "just" (an hour ago or so) read your post, bisected to the offending commit, tested things, and am pleased to confirm that it all seems fixed now. Thanks again for telling us about this, and sorry for not having caught it sooner!
ps. I have other reported bugs that haven't been fixed or replied to. Is it worth even posting here anymore?
I don't really follow all user forums that much, to be honest, and it's difficult to troubleshoot things for which we might not have gotten many details - forum posts aren't the greatest medium to have a conversation about a bug which might include sensitive data.
The best way to alert us of a bug with the site is to follow the report an issue with our site page and emailing webmaster@ with the various details.
I'll scour the other posts and see if there's anything else I've missed.
so what's 2.7 lbs in real money… (or even fractions of PHBs wrapped in carpet)?
I'll be sure to weigh him next time I see him and I wrap it on a carpet - but meanwhile here's the Reg Standards' Bureau's take on how much 2.7lbs is.
It's about a seventh of an adult badger, give or take. Or, in other words, you'd need about 1225 new Macbook Airs to have the same weight as one skateboarding rhinoceros.
I've noticed something odd about the RSS feed, some articles appear in it twice, coz they edited the title.
That seems to happen when the _url_ is changed, as the RSS feeds' "id" field is for some reason set to the path part of the story's URL, which changes if the story URL changes (which happens).
It seems like we should migrate to using an unique "id" instead, but we need to do that from a certain point going forward or we risk all RSS readers seeing all stories as being "new".
Thanks for the bug report, I'll add it to our pile and see what can be done about it.
Side note.. I miss the "hours" for post (posted X-hours or X-days ago). GMT Is not my cup of coffee/tea/adult beverage. I note that the articles "time" isn't in GMT... yet.
Could you elaborate on where you're missing what, please? Email to webmaster@ if you fancy.
The date/timestamps in the HTML usually show the date/time in GMT, but there's some JS which runs and changes them over to relative time.
So if you're running JS, you should be seeing relative timestamps in most places (but some, as for example an article's "date line" isn't one of them) and any other "full" timestamp is meant to be displayed in GMT.
If you (are running JS and) aren't seeing a relative timestamp, or if a "full" timestamp doesn't look like isn't in GMT, that's a bug on my book, and I'd rather hear about it (at webmaster@ please!). Thanks!
Not on my phone it doesn't, still 4 headlines to a row on that. If I change to request the mobile site [...]
Correction: when you ask your browser to display it "as a desktop site" it shows you the 4 headlines; if you UNTICK the "desktop site" it goes back to being responsive.
On Chrome one can tick the "Desktop Site" box, which used to "just" remove the string "Mobile" from the user-agent string. This was useful as some websites were hell-bent on doing user-agent sniffing, and on serving "the mobile version" to user-agent strings which advertised themselves as "Mobile".
Unfortunately, that setting has been in recent times updated to also make it completely ignore the "viewport" meta tag altogether, which is what causes your mobile device to display the "full 1000px width" website in your small phone's viewport, and is what makes the website be unable to "be" responsive.
See also this commit which is where the "feature" (ach, thwwwp!) was introduced by them.
I'd recommend using Firefox instead, but it looks like they also decided to implement the same "feature", as can be evinced by this bug.
IMVHO, the setting should be split in two for "pretend to not be a mobile device" and "force site into desktop mode", but I digress.
Thus, in the two most popular mobile browsers I have access to, tapping "desktop mode" makes all the responsive work we've done moot, and it seems like it's "by design".
Personally, if I don't like what happens to a site when I click "desktop mode", I don't click "desktop mode" and get on with it. I personally prefer some sites in one way, and some in another. YMMV.
There's a chance that we may be able to "fix" the issue by adding some JS which looks at the device properties and alters some other properties to "kinda force in" the responsive mode, but I'd avoid doing that if I can't help it - as I'd rather the users were empowered with the ability to choose what happens to their device.
Which, in your case might mean you wouldn't want the "desktop mode" to be "on" for the homepage or, I guess, for article pages either, as they're also "responsive".
Sorry, didn't see those.
The "contact us" page on the footer suggests e-mailing webmaster@ "for tech stuff" (and links to a page which explains what kind of information would be helpful to receive) as it's otherwise difficult to find all places where we might be mentioned.
I don't keep track of all forums, and sometimes forget to check old ones. I'm a commentard just like you.
There's a "web application firewall" in front of forums, and some content being submitted on forums "triggers it", somewhat heavily. It happens. Thanks for bringing it to my attention, I'll have a look at what we can do as soon as I can.
About the opt in/out being JS-based: sorry, we ensure that all of the basic functionality of the site can be used without JS, and then use JS to "better" that experience (see also: the up/downvote buttons, which work perfectly fine without JS but offer a nice AJAXy experience with JS enabled). The opt-out link isn't a "basic feature" of the site, at least according to my definition.
As the whole feature is JS based, its presence is also done using JS - in order to not have a half baked thing which would show a link and nothing would happen when it's clicked.
Its almost as if there should be lots more "headered" sections below "Latest News".
Like the "most read" unit, with a different background and a "Most Read" title?
All the others boxes under "latest news", at least right now, are stories ordered in descending order of publication time.
The list is kinda "interrupted" by the "most read" row, and then it continues on after it.
dig AAAA regmedia.co.uk will give you a result. We've had IPv6 on the domain used to serve most images from since donkeys ago, as it was easy enough. For the main domain, there's still a bit of work to do.
As I stated the last time, IPv6 is an ongoing "icing on the cake" thing, with no "business priority" whatsoever. It'll get finished when feasible.
As you also state, there's no requirement to demand IPv6 at this point in time.
Even if you had a IPv6 only connection, you'd still be able to access an IPv4 only site via a tunnel, in the exact same way I'm currently accessing the IPv6 web, since my "business" ISP is utterly unable to give me a native IPv6 connection.
It'll come, Soon® (but unlikely to come this month)
While we're thinking (re)design, I'd very much prefer if the "Expand comment" toggle in the forums/comments either went away, or perhaps if it was a configurable option.
If you're an "active enough" user of these forums (i.e. if you qualify for your comments to be automatically approved), you'll now be able to toggle the option. If you've not ever set it, if you try expanding a comment you'll find a small message hinting you to pick your preference on the matter.
You can head to the "My Forums" tab of your "Edit my details" (account) page, and you can toggle the "Switch off automatic post fading" on if you'd like.
Seems you have reduced the number of articles visible on the first page from 40-odd to 30-odd
Old homepage count is: 4 "top stories"; two rows of 3 stories; don't miss story, and 1 story; 12 more rows of three stories; 5 "most read" stories on the RHS. That's 4 + 2*3 + 1 + 1 + 3*12 + 5 = 53 stories; -10 (if you don't want to count the hand picked ones) is 43 "chronological stories".
New homepage count, based on current layout at time of writing: 4 "top stories" (or 1 "breaking news" which isn't currently up); 7 stories; 4 most read; 5 rows of 4 stories; one row of 3 stories + ad; 4 rows of 4 stories = 4 + 7 + 4 + 5*4 + 3 + 4*4 = 54 stories. That's one more than the "old" homepage. If you discount the hand picked ones (4 top stories + 4 most read) we're then at 54-8 = 46 stories. That's three more "chronological" stories than the old homepage. If there was a "breaking news" instead of the "top stories" block, it'd be 51 stories counting all of them, or (still!) 46 discounting the hand picked ones.
You're absolutely right in pointing out that we're showing one less "Most Read" story on the new homepage, down from 5 to 4.
The amount of stories shown on the homepage has grown and shrunk over time. In fact, I've twice halved it in the past few years (since the last EOY 2014 redesign) as not many people were actually reaching that far down. Less is more. The amount of stories on the homepage is, though, something that we can easily iterate on if we want. We've picked a number we were comfortable with and which made sense in the framework of the new design.
On demand image loading is "fine", however the new site appears to be performing processing even after the images are loaded, which is almost certainly what is causing the stuttering.
If you scroll "that far down", you'll likely have two things happen on scroll: delayed image load, and possibly additional ad load - both happen only if they require to. We've gone to great lengths to ensure that the delayed image loading shouldn't strain things at all.
The old site, using the same browser, and all that, exhibits none of the same problems, therefore it is something related to the new site code.
I'm fairly sure the old version would just "feel like" it's better when scrolling, at the expense of that time being spent at load time. I might be wrong, though!
CSS media selectors can be used and the images shouldn't be loaded unless required
You're right, "shouldn't". Unfortunately some browsers still do, and instead of having to go the '90s style of doing browser sniffing, we've decided for a simpler, and mostly better, client-side solution.
I remember saying "if you keep it, at least don't lose the working non-js fallback", but it fell on deaf ears..
It must've; apologies, I'm partially deaf and don't read forums all that often.
... so the best way to get this sort of "techy" feedback to us is likely to email webmaster@ - emails there usually get replied to fairly quickly (or never, depending).
See also: https://www.theregister.co.uk/Page/problem.html
Web log analysis, if configured, could give an idea how useful it is ... as you can set yourself up to log all requests quite easily (spot the person who thinks whats the use of GA when you can log stuff & be unaffected by js blocks, GA blocks etc)
We use both, but each to their own purpose.
In an ideal world, "web log analysis" would be the best of the crop, but how do you propose one filters for real, actual users ONLY (the things we're most interested in knowing whether things work for) instead of the zillions of differently behaving crawlers?
For the use case I highlighted, using GA gives us the best 80% of gain for 20% effort. Going the "analyse log files" route for that gets me instead pulling my hair out, and I'd rather keep them for the time being, thanks.
For other stuff we absolutely rely on log file analysis; each has their own purpose, and they're not - to the best of my knowledge and experience, interchangeable.
Do we actually see different featured stories depending on where we are located
Since time immemorial, the homepage has had "editions" - US, AU, and "GB/Rest of World". The list of stories on the homepage slightly changes depending if you're in US/CA, AU/NZ or elsewhere; very few stories are set to have an edition, but it can be noticeable.
All of them are shown in their respective section, though.
Similarly, the Editorially-picked stories (top stories, don't miss, etc) are also picked by geography.
This allows, say, the AU or US edition to highlight a really interesting "local" story which wouldn't otherwise have the same global importance - while at the same time allowing a particularly interesting "global" story to be able to be shown in that same spot in a global fashion.
Remember that Google [...] only run for those of us who don't block them [...] any data you (don't) get from GA is likely to be substantially more skewed [...]
We do use url-based tracking elsewhere, i.e. on whitepapers - which isn't ads-supported - where we track the "source" for a download, to be able to tell what works (newsletter link, RHS link, "most read papers" etc) and what doesn't. As it's not ads supported, and as the "business" of that site only relies on people downloading whitepaperes, we can't merely use GA as we'd indeed lose a lot of trackability.
That said, you might concede that for the ads-supported site we're instead far more interested in the behaviour of those seeing ads (as the site is ads-supported) which are unlikely to see ads but block GA, as those are likelier to be the ones that keep the site afloat - money wise, not merely comments wise.
Perhaps the Register would like to explain "hidden cookie" and its full implications?
Click here to enable the magic hidden cookie to opt-in for the 2018 redesign
The cookie expires after a week, at which point you'll return to the current design.
That's pretty much it.
The link (well, the redpill page's JS, which can be read) sets a cookie, called "test_redesign", and sets it to value "2018", valid for about a week. Clicking the "Back to Classic Homepage" button instead sets it to "off_2018".
Our Apache configuration ensures that even when your preferences are set to seeing the mobile version of the site, that cookie "takes over" for www's homepage, and shows you the new version; on our back-end, we simply check that the cookie exists and has value "2018" and if so we stash a variable, making the templates do what they need (set classes on the body tag, output a different SSI than the "classic" version, etc).
The distinction between "2018" and "off_2018" moreover allows us to see how many opted in and "stayed there", vs how many opted in and quickly (or not so quickly) "went back".
As to the redpill page, that's mainly been used in the past in order to see currently running A/B tests without influencing the outcome of them; i.e. being able to see "revision 2" of a unit, without the page view and/or the click "being counted" for the experiment. As it's meant to be a temporary setting one does, the related cookie's set to expire in just a week. We merely reused that facility to allow you, dear users, to opt in for a relatively short time - without "forcing" you to be part of this alpha/experiment for too long.
Sorry, not going to bring back user-agent sniffing for _everything_ unless I really absolutely must, and only for a few things. It's 2018, not 1994.
We do something like it for our CSS (we serve different CSS to different browsers, to ensure you don't end up downloading too much CSS which is completely useless to your browser), mind you.
We do some similar tricks for supporting HTML5 for IE8 (so as not to burden most users with loading things like html5shiv) but we've got to draw the line somewhere between "let's fix the rendering for those few silly browsers" and "let's make our HTML templates a huuuuge chunk of IF/ELSE/ELSIF based on which flavour of the year browser they are". Macros can help, sure, but that's not the point.
Feature detection / progressive enhancement is where things are at, and we can't "just" use HTML+CSS for _everything_. For some things, we require JS. They keep things tidy and sane for us, and they hardly change much for most users.
Not all users run with ad blockers, noscript, images disabled, etc. etc. There wouldn't be a site at all if that were the case.
I think it's not at all obvious to (m)any of us that "Top Stories" contains only 4 articles: the way that the next row just continues straight after those first 4 articles, I really thought that was a (long) continuation of "Top Stories", and not actually the start of the "Newest first" section.
I completely "get" where you're coming from, but may I point out that the "classic" homepage has the exact same unit (and has had that for 3+ years) and what's changed between "classic" and "new" for that unit is... merely where the "top stories" title is (moved from right to left) and how the "main" pic is portrayed? :^)
I take your point that the "separation" between those section isn't as clear to many people as they'd prefer; we did briefly AB test a "dividing header" between the top row and the slightly lower rows, but the result from that was roughly inconclusive. We'll see!
If you had had a, say, "?src=mostread" parameter in URI links from the "Most read" section, you would be able to tell from your webstats whether (m)any people actually do find it useful. I know that I have literally never used it myself.
Unless the client-side devs screwed something up, we've tracked clicks on "most read" since its inception (and separately, when the RHS "most read" unit used to come in a few A/B variations) and continue to do so in this new design, "simply" using GA, with sampling - and a little chunk of JS.
Re your "how many find it useful", I'm not looking now at the actual stats, but speaking in general... "most read" is quite a good source of additional page views for enough readers to make it worthwhile to be kept. It's maybe not as good a source of additional page views for assiduous readers who've already read those articles, but it certainly is for readers who find the contents of those highly popular articles interesting, as they've not seen them before.
Same goes for all other "editorially picked" slots - they're "pinned" because they'd otherwise "fall down" in the sea of bland, ordered by date published articles - and they'd risk getting missed by less assiduous readers.
If you've not read the news on the site for a few days, chances are that between the "most read", "top stories" and "don't miss" slots you'll find good articles to read - although you might also do well looking at the homepage for recently published articles which might not have had enough time to "rise".
Hope this makes sense! Not all readers are as assiduous as most readers commenting on this article; not all readers actually comment on articles; not all assiduous readers comment. Not all commentards read the articles, either...
In general, this new design tries to give the Editorial team more ability to shape the homepage in a way they weren't able to previously; moreover, it has been a pretext for also going towards responsive design / mobile friendly - which we weren't previously.
Many design matters are mostly a matter of personal taste, and one's choice on what should be on a homepage depends on how they use the site. We have to cater to a lot of users, very different between each other. It's sometimes the case that what works for the power-user hurts "new" users, or the other way around.
It's a difficult balancing game.
I agree; unfortunately, this is what allows us to simply NOT load those images at all on device sizes which won't be showing them. I'm not aware of any HTML+CSS-only based solution which allows them to NOT be loaded if they're not going to be shown.
Even if you set an element to "display:none", they will get loaded, and that's wasted bandwidth for mobile users.
We have to draw the "JS as enhancement" line somewhere.
hmm .... I'm looking closer now. Is "MOST READ" just those four articles in that box and the remainder of the bottom of the page all chronological?
It's not really clear
The "most read" unit has a distinctive light grey background, in contrast with the white background used by the other stories, which at least right now are in chronological order.
This all points to the "most read" unit maybe needing a little further hint that it's really just those four stories... but IMVHO the background colour change should be enough.
The new layout is "row based". Each row may have different content, but that content is limited to that row, and doesn't "bleed over".
That means, the "top stories" is just that very first row of stories, comprising of one with images, and three without. Those are editorially picked. You might see that it's a "whole section of one row" as it's got a distinctive border before it (well, next to its title) and after it, delineating it.
You may see instead a "breaking news" row, of one story. If set, it's shown _instead of_ the "top stories" unit.
After it, you'll see a chronological set of stories - from most recently to least recently published.
We may instead show you a row of four "most read" stories; that'll have a distinctive light grey background. After that row, the main content resumes.
Or... we may show you a "don't miss" story. That one will be Editorially picked, but the three stories to its right will be the "rightful" stories, from most recently to least recently published.
Or, there may be an Editorially picked story, "stickied" in that position. After it, there'll be three more chronological stories.
Interspersed, you'll see about three ads; some will be full-width and won't impede the display of stories before and after; others will be usually set to the right (or left!) of stories, and the three (or five) stories preceding it will shrink slightly, as (at least on desktop) we can only display ads of a given width (300px or so) on a desktop-sized device.
On a mobile device, the "most read" unit is also four stories, and also has the distinctive background.
Nothing's changed with regards to our displaying stories "generally" in most recently to least recently published order. It's kinda literally just how we portray the stories that has changed.
The redesign alpha seems to show just a few of the most recent or perhaps pinned articles up top followed by a 'MOST READ' section which I presume is based on popularity.
It's one ROW of FOUR articles, with a distinctive grey-ish background. It's the same four articles which are shown on the forums or "old homepage" RHS.
The row below "continues on" with the chronological article list.
What I take from this is that it's not too clear to many that the "most read" bit only applies to that row of four articles, _despite_ the distinctive background.
On mobile: I can't really tell the difference.
That might've been due to a blunder on my (Apache config) part - as we have an "edition switcher", mostly for mobile, which allows you to always see the mobile site if you've got that cookie set; and the "redesign cookie" wasn't taking over.
It now is, so... even if you've got your edition preference set to mobile, you should be seeing the new homepage if you've opted into it AND are looking at "www", not "m".
I like that the timelines are now correct
Both the new and "classic" homepages have stories ordered from descending published at date, save for 1) the "don't miss" story, which isn't currently shown on the "new" layout - but could; and 2) for "sticky" stories Editorial decides to place somewhere on the page; now replaced with a similar method.
The _bulk_ of stories are ordered; some are sticky somewhere. This hasn't changed in a long, long time.
the huge white bar at the top with a single button ("Back to classic homepage") is not supposed to be there in the long term
That's indeed only shown for the opt-in users, to allow them to go back to the "classic" version without having to look up the article, go to the "red pill" page and have to figure out that clicking "rm" removes the cookie ;)
are you getting rid of mobile.theregister.co.uk ?
Not a definite answer, and not in any official capacity - but "likely".
The way things are going web development wise is towards having responsive websites, and this (if and when done right) negates the need for having multiple versions of the same site / content (disregarding AMP for a minute).
We've already gotten rid of the mobile article pages, in case you haven't noticed. They're responsive, and the "www, responsive" version suffices. Next up will likely be getting rid of the mobile homepage - as this new, responsive homepage + our current "edition switching" logic suffices pretty well.
Chances are we will likely make each "page type" responsive, and kill the related mobile-only version as we go.
Biting the hand that feeds IT © 1998–2019