Food for thought
3D'ing »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Food for thought
« on August 8th, 2013, 03:37 AM »
Browsing around the intarwebs I found this article.

http://limi.net/checkboxes-that-kill

It's an interesting argument specifically about Firefox but it does make me want to go back and look at what we're doing...
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Auk

  • Can I get a Box?
  • Posts: 64
Re: Food for thought
« Reply #1, on August 8th, 2013, 09:44 AM »
Interesting indeed. Lol, when I started using computers, I never messed with settings. Mostly because I did not know how to. I've worked on many computers used by non-tech savvy people and those with Firefox browser installed never did any of the above. :lol: It's a good thing for websites I've developed, I never relied on javascript and "fake it using images with CSS" tricks.

I've used three of those check boxes before, but always knew to change things back. Legitimately, I had a really bad connection and wasn't all too interested to see pretty pictures.
Quote
Override automatic cache management
I learned what this is about. A lot of webpage authors would teach how to get rid of cache... Instead of clearing cache every time a webpage would not load the way I expect them to, why not just permanently disable it? I then disable this to always get fresh content. This shouldn't be as harmful to do than it would've years ago. I do not know the ratio for people around the world who has good connection opposed to bad connection. Mines below average. For this to be brought up, I would imagine a good chunk of 98% of people has horrible connection.
Quote
Turning off ssl & tls
To find someone who would actually do this wouldn't surprise me, I've seen a lot of dumb stuff people do with their computer. I have yet to witness this. To be fair, most people wouldn't touch this.
Quote
The entire certificate manager
This option is fairly buried in ADVANCED options, with techy-terms that should instinctively tell you that "you have no business here."

Nothing is more despicable than respect based on fear.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Food for thought
« Reply #2, on August 8th, 2013, 07:01 PM »
Note the key point that the author makes, more than once, that some of this stuff is relevant for developers and that alternatives should exist for developers, e.g. in the dev tools area. But not in the main options. Perhaps not in a UI at all, just in the about:settings area, or exposed via a plugin for developers.

Turning off cache... funny you should say that. How many times have we asked people to hard refresh Wedge? Yet there are semi regular CSS changes... answer: we generally don't because we have a system that pushes a different 'filename' to the browser so it won't be cached. As a rule you should assume that a user will have a given thing cached and if that's a problem, rename the thing. One suggestion I've seen was to have files include the date of release in them.

Telling users to turn off cache is generally a really silly thing to do because it's not a per site cache. It's browser-wide meaning that everything everywhere has to be redownloaded. Which for a per-site exception is ridiculous. And the fact that the site owner has control over how they send you things means they're the ones who should be responsible for dealing with it - if you routinely have to tell users to empty their cache, you're doing it wrong. (I'm not even sure why we had to ask users to hard refresh with the smileys, actually... it certainly surprised me that we had to)

As far as turning off SSL/TLS goes, that's a classic example of the point the author is trying to make... who would legitimately turn it off? Anyone who is smart enough to know to turn off SSL or TLS should know how to do so via an about:settings type page. There is no reason I can see for having it as a UI item, especially not a fairly prominent one.

Auk

  • Can I get a Box?
  • Posts: 64
Re: Food for thought
« Reply #3, on August 8th, 2013, 07:35 PM »
Key point taken. :) Now that you brought up the cache thing, I did had some issues where users on my old site couldn't see new CSS changes, so I made a random URL parameter which helped the situation, eventually, I decided to just manually rename files.
Quote
Turning off cache... funny you should say that.
Opps, I meant to say "Webmasters asks users to clear out cache", not turn off. :^^;: Happens really often I see people being asked to do that. I turn off to avoid experiencing any problems/miss-out on anything new. Yes, that is silly having to tell users of your website to do that.
Quote
we generally don't because we have a system that pushes a different 'filename' to the browser so it won't be cached.
I like this. I am working on a project that could use a feature like this.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Food for thought
« Reply #4, on August 8th, 2013, 07:52 PM »
Well, in Wedge's case, the CSS files aren't really CSS files and need to be run through a preparser to make actual CSS. All that happens is that we look for the most recent file out of all the ones that will be compiled together (parent + sub skins files) and use the most recent one's timestamp as the basis of the filename.

For example, the CSS files I see requested in this very page load are:
chrome29-member-828953.css.gz
editor/chrome29-member-647273.css.gz
smileys-cyna-900.css.gz

The browser is needed because some of the constructs in the WeCSS/Wess sources are browser independent (e.g. border-radius, gradients etc.) and the compiler will add the correct browser prefixes where needed. We have separate CSS for members and for guests (because we don't need to serve everything to everyone, only serving the stuff to guests that guests will see) to save bandwidth, and then the timestamp component.

As for css.gz, if the browser supports it, we'll send it pre-compressed - that way it doesn't have to be compressed every request by Apache/nginx, but only for those who actually need it to be served that way.