[criley]

Requiring a refresh is not outlandish. If they failed to load the content due to network error, they will already be used to that kind of flaky connection and the refreshes it requires.

Specifically building your app to attempt to handle the "bad data connection" use case that users already are familiar with in the context of the internet seems like bad programming.

Why provide a usable but substandard experience when those users would get a superior experience after a simple refresh?

As for the "turned it off crowd": in terms of web apps, who cares? If you've disabled Javascript, you're not looking to use web apps -- period. Javascript is required to use web apps for anything other than fancy form posting...

Of course, every site's audience is different, and you should prioritize your development for your audience.

[sc0rb]

It's annoying when you're using a different device in a locked down environment to have to deal with pages braking because some JS (or other) won't load on whatever piece of junk browser or device I have to use. I had this issue a lot when traveling through Asia, I never realise how bad accessibility was until I had to use crap phones and dodgy computers to access airline websites.

For the love of god please provide a BASIC fall back!

Slightly adhomien edit, but I think you're ignorant and live in a bubble. Not everyone uses their computer, or has the same level of access, like you do.

[criley]

What you call a bubble, I call my target audience. I don't mind that I accurately target my audience and prioritize my development towards them.

If information is what you care about and not design, style, or functionality, than my pages are perfectly readable on a screenreader. It will look and function like shit but the people who see it that way A) expect to or B) are not my target audience.

But you're right, it's a bubble. If my audience included people with poor data connections in Asia, then I would certainly approach the problem differently.

However, when it's just one guy making something, prioritization and cutting out the nonsense (like bad connections from Asia) are vital ;)

[sc0rb]

If any of your target audience may use your service from a less than desirable connection or device then you should try and make it as accessible as possible. Falling back to non fancy CSS and JS is vital.

It seems that a lot of services don't really understand their target audience, why would an airline or online travel insurance firm make JS mandatory?

[criley]

>It seems that a lot of services don't really understand their target audience, why would an airline or online travel insurance firm make JS mandatory?

Because they wish to offer any form of rich experience that goes beyond form elements and form submission? Because they want date pickers, column sorting, marketing tracking, transition effects and a hundred other UX tweaks that are only possible through javascript?

Why should airline/online travel forgo modern user experiences? To satisfy a statistically negligible amount of their traffic that cannot see it?

At some point, horses aren't allowed on roads, and users need to buy a car.

[sc0rb]

They can still have all of that for most of their users. Users that can't use these newer features should be offered a simpler more basic experience. Just because it's a minority of users that want to access your medical claims portal from abroad (who'd have guessed that this would be a valid use case for someone who has bought world wide health cover?) this doesn't mean that you should lock them out.

You are very short sighted. I hope you end up in a position where you need minor surgery in Vietnam during your gap year and can't enter the claim in the insurance companies system because they insist that ALL user must be able to see their fancy drop down menus with rounded corners OR not being able to book an onward flight from Cambodia therefore being refused entry because you can't prove that you plan to leave in the next 3 weeks all because the internet kiosk you're using is blocking the CDN that pushes some crap JS that adds nothing other than eye candy.

What's wrong with creating an alternate UX without all the overhead?

I hope you suffer the consequences of your own short shortsightedness.

Also, FYI, horses are still allowed on roads.

EDIT (can't reply) I think you'll find that medical insurance sites and travelling / booking sites are very similar and attract a very similar userbase. People book flights ticket and medical insurance, people fly then use the medical insurance when they have too. You seriously do live in a bubble, i have a feeling you are an American who isn't very well traveled outside of his own country and only uses medical sites in the context of your non state health insurance. You probably aren't the kind of person that would use any of the services I care about.

SECOND EDIT.. I spoke about my two target services from the offset and did not switch context. Do you not realise how these two sites / services go hand in hand?

I just got back from skiing. I used an airline site and medical insurance site for the same trip.

[criley]

>You are very short-sighted

Haha. We went from talking about my 1-man development website, to travel sites, to medical sites.

All because each example is a better fit for your argument. You don't warn me when you change the context of our conversation, you just do it and then insult me afterwards for not meeting your newer demands.

Medical =/= travel =/= my site.

Each are fundamentally different industries with dramatically different requirements. Obviously you have to meet the requirements of your industry and your users. I have CONSTANTLY SAID that you must prioritize your users. Medical users ARE NOT travel users ARE NOT blog users.

You're also failing to take into account a team versus one man. One man or small teams trying to launch have to prioritize their MVP and their main audience. Massive operations with dozens of developers SHOULD meet everyone demands, because they have the time and talent to do so.

When you're capable of not context-shifting a conversation to continually cast your argument as superior, I think this chat can continue.

Otherwise, you're just shifting and insulting me for your own jollies, and you'll excuse me for not going along with it.

Good day!

EDIT to your EDIT:

I currently work in healthcare IT after transitioning from a major travel IT company. The requirements are NOTHING alike, really nothing alike at all. The types of users and the requirements placed on the organizations by regulators are dramatically different. Medical is a WHOLE different ball game with tons of people to answer to.

Also, people can be expected to not book a plane flight with a bad connection on an old phone. "Wait until a better connection" is the standard response that has worked thus far (or call your secretary/company to handle it).

When it comes to medical data, waiting is less of an option and getting a good UX is less of a requirement.

[drewmclellan]

If a load fails due to network issues, the user won't always appreciate that the fault was down to networking. The site might just look broken.

If the failure wasn't related to a network issue (either bad data, or perhaps a buggy JS interpreter on their device) then refreshing won't help. The site will still be broken.

My point is that we can plan and build in such a way that JavaScript failures don't break the page. It's a little bit more work (doing things well usually is) but a reusable component library is absolutely the right place to focus that effort. Everyone then gets the benefit with no more work required.

[lukifer]

I agree that the NoScript folks can be ignored for apps. However, for web sites which consist primarily of rich documents, it's polite to at least try to convey the same information.

> Specifically building your app to attempt to handle the "bad data connection" use case that users already are familiar with in the context of the internet seems like bad programming.

Au contraire: It's the height of good programming to attempt to predict and handle as many real-world errors as humanly possible. If I'm writing a USB device driver, you'd best believe I should try to do something sane if the cable comes unplugged, rather than just saying "don't do that".

Also, not all users will understand that components didn't load (many users still don't even know what a browser is!). And if the failed load is due to a proxy/firewall/DNS problem, or just a straight-up bug, a reload may not solve it anyway.

In any case, you're spot on about prioritizing development to the audience. Guidelines can be a good start, but there's no "one size fits all" for the web.

[criley]

>Au contraire: It's the height of good programming to attempt to predict and handle as many real-world errors as humanly possible. If I'm writing a USB device driver, you'd best believe I should try to do something sane if the cable comes unplugged, rather than just saying "don't do that".

Should you devote a lot of your limited programming time to catching an exception that users naturally experience during USB operation and can be corrected by a simple "unplug and replug?"

I argue that you shouldn't devote undue attention to something that users naturally already handle.

But if your project is healthy and features are rolling out and you have the time and talent to waste on edge cases like this, then why not!