

Ask N.YC: How hard should we work to support those who don't use cookies or javascript? - falsestprophet

...or who don't use css or who use a really low resolution?<p>what does today's audience expect?
======
ssanders82
It might just be me, but it sounds like you're asking "how much should I sell
my car for" without telling us what kind of car you're selling. Ok, ok, maybe
that's a bad analogy. Honestly, at this point in my development career when
I'm designing a first iteration of a web app, I don't even worry about people
with 800x600 rez, or no cookies, or no Javascript. Again, it might just be me,
but that's like worrying about scaling to 1 million concurrent users when
you're first building your app - not worth the time. Sure, it would be nice,
and sure, some gov't agencies (I've worked for one, the Florida Division of
Emergency Management) require adhering to some handicapped guidelines.
However, you time is _valuable_. Keep that in mind. You're trying to maximize
the total utility to your users, and making 2 complete apps for JS/No JS (a la
GMail) isn't maximizing your time. Later, when you have xx,xxx,xxx users -
yeah, go for it; you could be turning away thousands of non-JS users. But, let
me ask you, do you have 1E8 users? Don't initially spend 20% of your time on
2% of your audience...

------
mpk
That really depends on what you're building.

Using cookies to run sessions is pretty much the norm, so trying to support
stateful application behavior for people that refuse to use cookies sounds
like a good way to waste a lot of time.

JavaScript .. well, if you're a public website then the whole thing should
just work without JS and degrade gracefully where you do use it.

Having specific functionality JS-only is fine for certain applications, but
it's considered good form (and for some government contracts - a requirement)
to present an alternative non-JS interface for accessibility purposes.

Check out <http://maps.google.com> with JS disabled, for a good example.

~~~
xirium
> trying to support stateful application behavior for people that refuse to
> use cookies sounds like a good way to waste a lot of time.

Some frameworks handle this automatically. At worst, you append a parameter to
each internal URL.

> JavaScript ... considered good form

Making your website degrade also helps visibility in search engines. Feel free
to ignore this consideration but those who provide graceful degradation will
have a small and sustained advantage over your efforts.

------
paul
It's good to make content accessible without cookies, js, etc so that it can
easily be crawled by Google. I wouldn't waste time making the interactive
parts work without it though.

Moving the session cookie into the url is a bad idea -- it creates security
holes (urls leak via referrers). Ironically, fear of cookies has actually hurt
privacy and security.

------
daleharvey
This came up at the hackers meetup in london last night.

Its a matter of the extra dev time vs reach of audience, which varies from
site to site, I would say on average, I assume a reasonable resolution, with
js and cookies enabled.

I dont think every person crippling functionality to cater for the maximum
possible market is a good thing for the individual sites or the industry in
general.

flickr came up as an example, but when flickr launched their 'organizr', you
could count a handful of large sites that used heavy js / ajax interfaces,
there were also a large number of photo sharing sites, while it wasnt the
reason flickr won the photo sharing wars, providing an incredibly powerful and
usable tool to let people work with their photos gave them a very good start.

Obviously for some sites (wikipedia) catering for handicapped users provides a
huge benefit with very little negative impact on the standard user.

However I dont think a strict requirement, and if your application benefits a
lot from scripted interface elements, go for it. If everyone sat and served
static text pages. handicapped users will never get to enjoy the benefits of a
fully featured scripted interface that will inevitably be created through new
demand.

<http://ejohn.org/blog/ajax-accessibility/> is also worth a read

------
Hexstream
Personally I expect cookie support since it's much harder to support a login
mechanism otherwise.

On the other hand, I'd use javascript only to enable nice interactive
additional features but the site should degrade gracefully when it's not. In
fact I should probably state that as: The site works normally without
javascript and "upgrades" if it's enabled. The "degrades gracefully" sounds
like "semi-supported, absolute last resort".

I wouldn't do an all-ajax site...

------
tlrobinson
It really depends on what type of site you're building. If it's a simple
website where the JavaScript just makes things a little slicker or easier to
use, then you should gracefully degrade for browsers with JavaScript disabled.
Same with CSS and low res.

If it's a complex web application, don't worry about the people without
JavaScript enabled.

As for cookies, I think it's pretty much expected that they be enabled for any
sort of login mechanism. The alternative is to pass a session token around in
every URL, but the moment they close the browser or open a different URL that
gets lost.

------
johnm
The most important part of the JavaScript (and Flash and Java Applets and...)
vs. non-JavaScript, et al question is much less about users and much more
about making sure that you site is coherently crawlable by the search engines.

If you're site isn't easily crawlable by the search engines then you're pretty
well hosed because that's where most users come from these days for most
sites.

------
bigbee
Start by building your best thing that works for most users. Most people work
in 1024 resolution or higher, and don't bother with disabling cookies or
javascript. Trying to support everyone right away is just like premature
optimization. Get something out first, then work to support exceptions if you
see that you actually have users that would want that.

------
mattmaroon
The simple answer is it's all about optimizing. Does making the screen wider
make your product more appealing to the 97% of people with >=1024px wide
screens? It wouldn't take much to compensate for the 3% of people who have to
sidescroll.

Same with Javascript. Who in your audience doesn't have that? If you're
building an app people will want to use on mobile phones, clearly you should
have an html only view. If you're making a project designed mainly for
desktops, then 99% of people have js and cookies on. If it adds any good
functionality at all, it has to be worth it.

The question, as posed, is to generalized to have a meaningful answer.

------
jws
Frequently your low resolution visitors are vision impaired and compensate by
making bigger pixels.

------
mark-t
Who's your audience?

------
rw
JS' foremost use is to serve ads. I block JS using NoScript. So, I conjecture
that a lot of people block JS for the same reason.

~~~
breily
It seems like it'd be a lot easier to use something like Adblock to block ads
- if you block Javascript you can't use GMail, Google Reader, etc.

Also, that sucks you were downmodded so much without replies.

Edit: I guess you could use GMail, but without the fancy look.

~~~
rw
While it's true that JS is used for a lot else besides serving up ads, the
most profitable way, on the margin, to use it (say, per line of code per site)
is by serving ads. If you really disagree, let me know of a something that
produces per profit per line of code!

~~~
daleharvey
thats a pretty strange metric to discern a technologies use. profitability per
line of code is a pretty vague metric, and using the same logic you can say
emails foremost use is spam, therefore block all email.

~~~
rw
Or not. Consider:

Email is used for many business transactions, and for other types of
meaningful communication between people. So, it can be estimated that email
tends to enable profit due to this relationship-building and information-
carrying ability.

