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 ;)
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?
>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.
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.
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.
Are you kidding me? Both sites have users that need to access various portals from foreign countries. That's the basic similarity between the two sites.
Wait for a better connection... oh yeah sure, I'll just go look for another internet cafe in the middle of nowhere on my travels.... Seriously, you're an idiot.
So many companies get this right. A few don't. I serioulsy hope you suffer
EDIT: I'm specifically referring to people that travel here. As you live in a bubble, I doubt this applies to you or the sort of work you do.
>Are you kidding me? Both sites have users that need to access various portals from foreign countries. That's the basic similarity between the two sites.
That is the most superficial comparison between two disparate industries that I've seen in some time.
Yes, both are websites that you access.
By this context: I visit mobile gaming websites from foreign countries. According to your analysis, mobile gaming == travel industry == healthcare.
You do, of course, realize that the regulation requirements behind the systems that deliver those websites are dramatically different?
Between HIPAA, ARRA, a bevy of other national regulations and 50 separate state implementations of Medicare/aid with additional privacy and other regulations on the state level, I hope you can appreciate that medical software requirements are fundamentally different.
Implementing a medical portal is an order of magnitude more difficult than a travel portal from the regulation and control side alone.
Put it this way: if you leak user data on a travel site, all you might have to do is write mea culpa and force a password change.
If you leak user data on a medical site: the fucking hammer comes down, public disclosure is mandated and _heavy fines will follow_.
These kind of systemic differences absolutely affect the end user UX and the kinds of priorities that developers have going into it.
Making sure spotty data connections work is less of a priority than making sure a secure connection is present when dealing with HIPAA protected data.
All I'm saying is... websites and portals that are accessed from devices and connections, in emergency-ish situations, should really have fallback modes so they work when I'm stuck in immigration in a third world country (or hospital).
long haul airline sites and medical insurance sites fall under this category. I'm not talking about this from any other perspective than accessibility under less than desirable conditions.
I don't really see how this has anything to do with American state laws. Accessing a portal that tells an insurance company that I need treatment abroad is a simple. Can you please burst your god damn bubble. We're talking about JS and CSS fallback not the united states of americas various laws in regards to medical records.
Yes, sites whose main audience may view it from those limited connections should devote resources to ensuring that they can access it from limited connections.
I clearly stated exactly that in my first original post in this thread. I said, always know your audience and prioritize your development for your audience. I don't know why you've missed me saying that 4+ times at this point. I guess it's because you want to "win" a debate, even though I made your point before you even read my original post.
>I don't really see how this has anything to do with American state laws.
Because accessing data requires you follow the laws governing that data regardless of where the request comes from.
>Have you ever left the US?
Have you ever programmed before? Do you know what software requirements are, or legal requirements, or any of it?
Honestly, you sound like a layman. 100% end user with zero experience in building a portal or medical software or anything else. "Who cares about laws, I'm talking about css fallback". Well, the people who pass and enforce those laws care, even if you don't. And they will make sure you care sooner or later, if you plan on staying in business.
That's the point. You have to care about laws because they're fucking laws! You don't get to just distribute protected medical data over insecure connections because it's convenient for end users! That's illegal.
And protected medical data IS DIFFERENT from non-protected personal travel data!
I know that understanding that difference is difficult for an end-user, but please respect that the concepts are completely different and pretending that "it's the same" only hurts your ability to understand the additional complexity that security laws like HIPAA introduce.
Please do not talk to me any more. I have no interest in replies and have provided this one because you keep stalking me in other posts, so I wish to provide closure.
If you want the last word, please take it here and no where else.
Please stop following me and posting on unrelated threads, it's extremely immature.
You're an idiot, I'm talking about the accessibility of a data entry portal. There's no reason to not make it work in sub optimal conditions if ANY (not just your main) of your user base are likely to be in those conditions.
This has very little to do with data protection laws. I'm not talking about making your data secure, using ssl, redundancy in your database etc. These are all requirements but this is not what I'm talking about.
Simple accessibility in sub-optimal conditions. Stop trying make your small minded opinions the focus of this. Do you even own a passport?
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 ;)