Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment: Re:Offline reading (Score 1) 114

by BronsCon (#48910183) Attached to: Twitter Moves To Curb Instagram Links
You're also an edge case in that most people simply wouldn't care. The vast majority of users of any given site have connectivity while they're using the site.

That said, I do wonder what some of these implementations do when a user tries to print the page. Does the print view also lazy load, or does it load all of the content because, well, you know, it can't pop it on the printed page when you go to view it; it has to be there for printing.

In short, I guess I'm asking if you've ever tried the print view as a solution for your use-case, as it would have to be *severely* broken (in which case, let the site operators know, maybe they care enough to fix it) to not do pretty much exactly what you want. And if they're doing lazy loading and don't have a print view, well, then they're just asshole developers; in which case, you should probably let them know that, as well.

Comment: Re:Offline reading (Score 1) 114

by BronsCon (#48906533) Attached to: Twitter Moves To Curb Instagram Links
I've encountered, even on popular sites (like Slashdot, for example) with no lack of resources, partially-loaded pages. By which, of course, I mean the text only partially loaded; the tail end of the HTML just never got to me. I never expected you to read, much less comprehend, anything; you certainly didn't do so with my comment, or you'd realize that a cursory scroll to the bottom to make sure there's a footer there would suffice. You know, some cursory check to ensure that the data you have and the data you think you have are, in fact, the same data.

If you can't be arsed to do that, then you weren't interested in reading that content in the first place. Right? Right.

Comment: Re:Social Networking is a mess (Score 1) 114

by BronsCon (#48901733) Attached to: Twitter Moves To Curb Instagram Links
I'm not disagreeing with much of what you're saying, and I'm certainly not claiming it's done right more often than wrong. Quite the opposite, and I admit as much. My point is that it is wrong to decry the entire concept of on-demand loading simply because most people get it wrong; instead, try pointing out (as I am doing) how they're getting it wrong and how they can, instead, get it right. That's how you get people to listen; because whoever gave the project the green-light in the first place will simply instruct their developers to ignore anyone who doesn't like their pet feature, out of hand, but you might get through that filter by phrasing your dissent in the form of a feature request.

Comment: Re:Social Networking is a mess (Score 1) 114

by BronsCon (#48900793) Attached to: Twitter Moves To Curb Instagram Links
1-3 are the result of shitty implementations. #4 is the result of you not checking to ensure the content actually loaded in the first place before you drop off the network; what if there was a server or connection issue? That would affect a static page just the same. It's akin to making a backup, but not bothering to verify that it completed successfully before unplugging the disk and putting it in storage; you don't blame the developer of your backup solution for your failure to follow bast practices, do you? #5 is a browser issue; try restarting it once in a while (I deal with this as well, and it also affects static pages). #6, well, I hate ever-scrolling sites as much as the next guy, I was never advocating for those in the first place; that said, there's also a right way to do that, but I can't say I've ever seen it done.

Finally,dynamic loading is worse for slow connections. People on slow connections load pages in the background or switch to a different task while the page loads. They're used to this, it's normal procedure when browsing. Dynamic pages break this. We see the page load quickly, but then constantly have multi-second pauses while consuming the content because the page keeps halting to load more content.

Well, that's not being done correctly, either, then. What *should* be done, so that users can immediately switch to a tab ans see content, is to load the content that is visible in the current viewport first, then content less than one full screen out of view, so it's there when the user starts scrolling. For many pages, that means just loading all the content, but for longer pages there will still be content left unloaded. The script loading the content should monitor load times and determine if a given bit of content is will take more than 0.5*[number of screens away] seconds to load, and load it early if it is.

Done correctly, the user shouldn't be aware of the delayed loading in most cases, and minimally aware of it in the worst case. Given that one side has bandwidth costs and the other side likely has either caps or costs, it's beneficial to everyone, but, again, only if it is done right. Which we can both agree it, typically, is not.

But, when you decry the practice in its entirety, you set yourself up to be ignored by the developer community as a whole. They hear someone who simply prefers to not have the feature at all; mind you, it's a feature their employer is insisting on having, so they're not allowed to listen to you. Instead, do what I'm doing, point out what is wrong with the implementations and pose solutions; then, the developers can listen.

Comment: Re:Social Networking is a mess (Score 1) 114

by BronsCon (#48900707) Attached to: Twitter Moves To Curb Instagram Links
Oh, I have plenty of patience. I'm develop full-stack, I know the ins and outs of the industry, probably better than most, and I know not every page is going to load instantly, and it's not always the site's fault. However, it is well known that most people don't have anywhere near that level of patience.

47% expect a web page to load in two seconds or less.
40% will abandon a web page if it takes more than three seconds to load.
52% of online shoppers claim that quick page loads are important for their loyalty to a site.
14% will start shopping at a different site if page loads are slow, 23% will stop shopping or even walk away from their computer.
64% of shoppers who are dissatisfied with their site visit will go somewhere else to shop next time.

Since when is giving people what they want a bad thing?

Comment: Re:Social Networking is a mess (Score 1) 114

by BronsCon (#48900681) Attached to: Twitter Moves To Curb Instagram Links
You seriously think the developers decided any of that? No, their decision was, ultimately, "implement this bullshit here, or leave and be asked to implement similar bullshit elsewhere". That, or starve. Also, there is nothing inherent in the use of javascript that affects security in any way; a site using multiple 3rd-party scripts and libraries and making tons of calls to external sources *might* introduce security vulnerabilities, but it's not a given, and a site simply using javascript to load a properly-sized or cropped image (e.g. to save bandwidth) isn't exposing *anyone* to a security vulnerability; if the image source turns out to be executable code and the browser decides to execute it, well, that's a browser issue and it would have happened just the same with a static HTML <img> tag.

As for your claims re: performance, well, I agree it can be overdone. But you're wrong in cases where it is done right. Loading and rendering only the data that needs to change is *much* faster than loading and rendering the entire page and, done correctly just as bookmarkable.

I can't help the fact that the people who ultimately decide whether developers eat or not don't allow them the time required to implement things properly. My workaround was to quit working for someone else, and I've seen the quality of my own work improve immensely since then.

Comment: Re:Social Networking is a mess (Score 1) 114

by BronsCon (#48897329) Attached to: Twitter Moves To Curb Instagram Links

Especially static content, and especially when the content of the article is a series of sentences punctuated by big squares that, rather than loading images, contain t.co redirects to the images that some doofus tweeted.

And this is where your understanding of the problem fails.

Again, this is a middle-management and bean counter problem, not a developer problem. The developers don't sit there and ask "How can we add more Twitter to our pages?" On the contrary, the bean counters say "We can save on bandwidth by letting Twitter and Instagram host our images, while at the same time monetizing our users through forced interaction" and the managers relay that as "Give us the ability to easily link to Twitter and Instagram images or go find another job".

And, of course, the developers do it. Why? And why shouldn't you fault them for it? Because they know damn well that if they go work somewhere else, it's just more of the same, from the same kind of shitty bean counters and managers who don't understand that this shit kills their user base, in turn killing their income. If they don't do it for their current employer, they'll be asked to do it for their next, and the one after that, and after that, and so on, and so forth, until they are unemployable. Even McDonalds won't hire them after they're on their 6th job in a year. Then they starve.

Comment: Re:Social Networking is a mess (Score 1) 114

by BronsCon (#48897307) Attached to: Twitter Moves To Curb Instagram Links
Jerky scrolling sounds more like they've got you using underpowered machines. There's no excuse, on modern hardware, for the process of loading and rendering an image to bog the machine down to the point that the UI is affected. I say this having used, and developed on, a single-core Atom based netbook, exclusively, from 2007-2010, without issue; but then, I tend to develop as though resources are limited, since that was actually the case for me for the first 28 years of my life.

I can totally see other developers, who haven't been conditioned to realize that system resources are finite and not everyone has the latest and greatest CPU and GPU with oodles of RAM and gigabit internet (I wish... 150mbps is the best I can get and it's not worth the expense), assuming, since their code only lags slightly on their maching (which they blame, of course, on the browser dev tools), that it will, at worst, only lag a little on the user's machine which, typically, is much *much* less powerful.

I struggled for over 4 years to get my former boss to see this as a problem. Former boss. For a reason. We started losing clients as more and more javascript was added to the sites we were hosting and page render times went through the roof, but optimizing client-side code was forbidden; it didn't run on our servers, so it wasn't our problem and, besides, it ran fine for us, so there must not actually have been a problem. Or so he said. Of course, I knew better, and I still do, but that knowledge failed to transfer and the bloat continues in my absence, getting worse by the week.

So, I really don't blame the developers implementing the shit code, even; it all comes back to the idiot telling them not to fix what's broken, because they don't see how or why it's broken in the first place.

I worked for myself for 7 years before taking that job and I watched the quality of my code steadily decline while I was there. I've only been working for myself again for a little less than 2 months and I'm already seeing the quality of my output shooting back up to where it was 4 years ago, and still climbing, as I've learned much over the past 4 years, on top of simply having better tools now than I did then.

Without that perspective, though, I see how easy it is to blame developers for everything, but the reality is much, much different in most cases and developers don't get to choose to write good code; they only get to choose between writing shit code for their current employer or for their next. Sometimes that's because the employer sucks and sometimes it's because they suck; I've talked about both here.

Comment: Re:Social Networking is a mess (Score 1) 114

by BronsCon (#48897123) Attached to: Twitter Moves To Curb Instagram Links
Bingo. Well, almost. What you're complaining about can be done effectively and correctly, as well. Assuming it's done intelligently, with properly-sized placeholders so loading the images won't move other content around and ensuring that images less than one full-screen-scroll away are loaded, it's a decent way to save bandwidth without annoying users. That said, it also requires estimating the user's connection speed based on load times for the images that have loaded thus far, so you can disable it and just load the remaining images (in order of appearance) if the user is on a connection slow enough that they might miss images while scrolling because they haven't loaded by the time the user scrolls past.

Don't get me started on sites that don't even start loading the images until they're scrolled into view and don't use placeholders, so the images, when they finally do load push down the content you were reading. If I understand correctly, that's what you're talking about and yes, as a web developer, it annoys me to no end when some code monkey pulls that shit and sullies my good name, and that of the other competent developers I know.

Comment: Re:Social Networking is a mess (Score 1) 114

by BronsCon (#48897099) Attached to: Twitter Moves To Curb Instagram Links
That is most definitely "not used properly". I may have misspoke when I said no image tags, actually, as my preferred implementation is to use a 1px transparent PNG as the default SRC for the image tags, so they can still be inline on the page, with width and height specified (via CSS, of course). Done correctly, as I was saying, no images or scripts load until the text content of the page has loaded and rendered and you are able to start reading the article.

It's not even that hard to do, but most devs don't take the time to think about it, usually because they're not allowed to spend their time on such things. Again, blame shit-tire middle management and bean counters for that.

We warn the reader in advance that the proof presented here depends on a clever but highly unmotivated trick. -- Howard Anton, "Elementary Linear Algebra"

Working...