Are there any analytics on how many people actually print webpages? [closed] - html

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Has anyone, with a large sampling, done research on how many users actually print webpages? I'm looking for some percentage values. .01%, 1%, etc actually print webpages.
It seems like a waste of time, to create design oriented print pages, if the stats extremely low.

It is very easy to create some print styles for your stylesheet to make printing easier on people.
As an example: http://www.alistapart.com/articles/goingtoprint/
In the same way that not everyone who visits your site will be disabled, the best practice is still to create sites that work for people with accessibility problems.

I don't have a link to a study for you but I'm very confident that it depends heavily on the type of content. I.e. the percentage of people who print a youtube video page is for sure much lower than those who print a recipe from a online cookbook.
So it's probably best to run your own study on the particular website where you need it. You can either make a little poll for the users of your site or track how often pages actually get printed.

This is not a metric that is usually tracked.
Since one needs to differentiate the regular page from the printable page, this requires a custom implementation on the printable version page that sends a particular tracking code/cookie.
It is not that hard to implement, one can even have printable pages tracked in google analytics or any analytic engine, but as I said it does require preparation and most people don't track this metric in particular.

It is possible through JavaScript to track the actual printing event with IE browsers. Considering users most likely won't switch to IE just to do the printing, it would give some sort of accurate indication of what % of the IE users, print the page.
For more information about the onbeforeprint and onafterprint events have a look at:
http://msdn.microsoft.com/en-us/library/ms536672(v=vs.85).aspx
Btw, I am not saying that collecting this data solely from IE users would give an accurate indication of the overall % of printed pages across all browsers, because IE is far more commonly used in office environments rather than home environments.

Related

Yahoo web mail is stripping out certain inline email styles [closed]

Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 months ago.
Improve this question
Yahoo web mail (mail.yahoo.com) is stripping out these inline styles, but keeping things like color and padding.
text-decoration
font-size
border-radius
text-align
font-family
Any idea why these are purposely being removed?
Example:
<span style="font-size:30px;">Hello</span>
becomes:
<span style>Hello</span>
What can be done?
This is the difficult part because options are few. Even with free market choices well established corporate entities have little to no business reasons to improve their products unless competition comes along. You could always attempt to file a bug report (like, where if even any where though...) and as usual wait decades for a(n intelligent) response (*cough* Mozilla *cough*). You could attempt to work around the issue (replace width with min-width in example). I've noticed that font-size: 120%; works just fine so consider what unit values you're using for testing.
You can make a different though, even if it's relatively small. I was wronged by a motherboard manufacturer in the mid-2000s and since then they've lost tens of thousands of dollars of sales because of me directly and who knows how much more based on the video I posted back then and that is just in the past ten years. The issue with Yahoo is different, at best all you can do is write a blog entry and link to other people talking about the issue to raise awareness. You could go so far as to disallow registrations from users with Yahoo accounts or greatly discourage users from using Yahoo accounts though that could lead to a loss of members so I wouldn't do something like that unless you've got something people really want. The state of HTML email in general is exceptionally sad at this point though most (at least technical users) typically have multiple email addresses.
You could always use <style type="text/css"></style> even though scoped CSS is not widely supported in 2017 except for Gecko/Firefox though it did seem to fix some of the issues for me that you mentioned you were having.
Lastly you can always provide a "view this email on our website" option; I see it all the time because HTML email is still a disaster (2017). I've even seen nonsense with developers sending email with html element (uh, it's not an entire page, it will be embedded, but you know, whatever...).
So try utilizing different unit values and even the contexts themselves. Inline-styling is the way to go and if that fails provide a website version of the email (with security considerations for email with sensitive data).

"One page" / "long front page" web design? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
There's a web design trend that I've been seeing more and more in sites I come across. The thing is, I don't know what it's officially called, so I don't know how to look for the topic in web design sites or blogs. I'd like to find tutorials and articles regarding tips and best practices, but I haven't found any and don't know what people are calling this design style.
Basically, it's having a long front page (or inside pages too) with lots of horizontal sections with big images and text. It's sort of like one-page sites, but it's not one-page. It's sort of like Parallax, but it doesn't really use the parallax effect (not necessarily at least). It also goes very closely hand-in-hand with responsive design, as it shares that long vertical format made for lots of scrolling.
A couple of examples of what I'm referring to: www.marketo.com, www.ginzametrics.com, www.kinhr.com
I'd appreciate any help finding the official name of this, if there's any, or also any related articles or resources. Thanks!
I believe the technical term you're looking for is single-page application or single-page interface.
Google search results for the phrase "single page website" show that it is used to describe the same types of sites. One page website comes up as another synonym (onepagelove.com provides a collection of single-page site designs, for example).
However, single-page application seems to be the most official and comprehensive term. Relatedly, it is actively used as a question tag here at Stack Overflow: https://stackoverflow.com/questions/tagged/single-page-application
They are "long page scrolling" designs. See: http://www.dtelepathy.com/blog/inspiration/long-page-scrolling-designs
A single page application is NOT the same as a "single page website". First of all, the difference between an application and a site is that a site is simply used to display information whereas an application provides a function or utility or service to the user. Applications are interactive by necessity. In addition, single page apps may have more than one "screen" or "view", but these views are loaded in via AJAX calls behind the scenes and do not require a page refresh. Examples of single page applications include Gmail and Facebook.
A single page website does not necessarily have a long page scrolling design.

Empty Lines in HTML source bad for seo? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I prefer to write my HTML clear, so I may use empty lines here and there - example:
<div>
<!-- Seasons -->
<table class="giantTable">
...
</table>
<!-- Prices -->
<table class="giantTable">
...
</table>
</div>
Today my new workmate told me that this is bad for SEO,
because Google would need more time for parsing the site and may abort with a timeout.
I never heard about this,
shall I really write Spaghetti-Code again?
Google do use page-load and rendering time as one metric (of over 200!) for determining your page-rank, so to an extent your colleague is right (although timeout's are not the issue - he is wrong on that).
However, you can have the best of both worlds :) Write your HTML as you normally do, and then minify it before deployment.
Note that there are a number of tools for analysing your site performance (both online, and as browser plugins - e.g. YSlow), and it's a very sensible thing to do. You can have numerous bottlenecks in your web-site, and can often get some quick wins that significantly improve the responsiveness of your site.
As always with optimisation though - measure first! Don't just randomly implement supposed improvements until you have measured the bottlenecks, and then confirmed the improvement is an improvement.
The sentiment isn't entirely off. Google does now consider the speed of your pages as a factor, and excessive white-space in code can increase payload size. Google themselves recommend minifying your code ( https://developers.google.com/speed/docs/best-practices/payload#MinifyHTML ), and this can be done without too much overhead on the web server.
I find the biggest culprit in dynamic websites comes from using loads of space in the middle of for/while loops, so cutting down on that can make a big difference. Also, try using tabs instead of spaces and you'll cut your white-space big-time.
Even if this were true (which I've never heard before however RBs point above makes a good point), there are many other things that contribute to your page ranking way more than what that would.
Google made an awesome SEO guide which I always check out, its really pretty and easy to read as well, what with all the pictures of Robots. Its definitely worth checking out - Google SEO Guide
It isn't bad at all, they ignore white space. Otherwise everyone would be trying to write code all on one line
http://jamesmartell.com/matt-cutts/is-excessive-whitespace-in-the-html-source-bad/
This document describes how to do SEO for Google (it is quite extensive). A first glance over all the pages doesn't say anything about compressing your HTML.

Why should I not use HTML frames? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I haven't used frames since 1998. They seem like a bad idea and in all my development I've never had a situation where frames were the right solution, or even a decent solution.
However, I'm now working with an internal web application written by another group and the entire site is built in a - header, left side menu, right side content - frameset.
For one, when VPN'd to my network I constantly get a "website.com/frames.html" cannot be found." error message. This doesn't happen when I'm on the internal network.
Second, the app has a built in email/messaging system. The number of unread messages is shown in the left side menu frame as "Messages (3)" but the count doesn't update as I read the messages. The developer told me since it was in a frame I needed to right click on the menu and 'Refresh'. Seriously????
So, my programming related question is, what reasons do you have for not using frames in a website?
Although they solved a problem at the time they were created (updating part of a "page" while keeping in place a non-updating part), framesets were criticised in terms of usability pretty much from the start, as they break generic functions of the browser, such as:
bookmarking, and copy-and-pasting URLs to share
printing the page as displayed on the screen
reloading the page: since the URL has generally not changed, you will often be taken back to the site's homepage or default frameset; manually reloading some frames is possible, but not obvious to the user
back and forward buttons are ambiguous: undo/redo the last frame change, or take you to the last time the URL bar changed?
The heaviest burden of avoiding framesets - including the same content on every page - is trivial to solve if you are using any server-side language to generate your HTML, even if all it provides is a "server side include". Unlike framesets, a server-side include could occur anywhere on the page; building a site with a server-side scripting language or templating system has other obvious advantages too.
There is still an advantage to being able to update small areas of the page without reloading the entire content, which can be achieved via AJAX. This sometimes leads people to create interfaces with all the problems of framesets outlined above, but that is hardly an argument in favour of framesets. Again, a site built with well-designed AJAX functionality can achieve things which framesets don't even begin to address.
One good reason to avoid frames today is they have been deprecated in HTML 5: Chapter 11 Obsolete features
11.2 Non-conforming features
Elements in the following list are entirely obsolete, and must not be
used by authors:
[...]
frame
frameset
noframes
Either use iframe and CSS instead, or use server-side includes to
generate complete pages with the various invariant parts merged in.
The #1 reason? Users hate them.
Even if they offered advantages in other areas (separation of code, application design, speed etc) they are part of the user interface. If users don't approve, don't use them.
Frames were vaguely useful when you had a static web site, to avoid repeating navigation menu in all pages, for example. It also reduced the overall size of a page.
Both these arguments are obsolete now: sites don't hesitate to serve fat pages, and most of them are dynamically built so including such navigational parts (or status, etc.) has no problem.
The "why" part is well answered above, partly by your own question (you hit a limitation, although it can be overridden with a bit of JS).
My number 1 reason not to use frames is because they break the bookmark (aka favorite) feature of browsers.
With the technology that exists today, frames have become obsolete. But if your legacy project still uses them, you can make the messages update with some ajax.
Just because of the cell phone iPad craze doesn't mean that highly functional full featured sites are suddenly "obsolete", and those who decided to make framesets obsolete seem to be the same complainers who never figured out their full potential in the first place, or maybe they're the lobbyists of the mega-corporate cell-phone and tablet makers who couldn't be bothered to make a decent frames capable browser for their itty-bitty screens.
Admittedly, iFrames can handle simple jobs like scrolling and/or displaying independent segments within a single page pretty well, and I use them for that inside my own frames based website, but to get them to work as well as the foundation for a site itself is a nightmare. Trust me, I know because my website is one of the most sophisticated frameset based sites on the Internet and I've been looking at the pros and cons of transposing it all to iFrames. Nightmare is an understatement.
I can already hear the whiners saying, "Well why did you build it that way in the first place then?" ... and the answer is A: Because I'm not lazy. and B: Because a frames based site is the most functional, visually appealing, and user friendly format for an information based site with hundreds of pages of content that doesn't have to rely on a server. By that I mean all but the external advertising can be viewed straight off a flash drive. No MySQL or PHP needed.
Here's some of the issues I've encountered:
The objection to orphaned pages can be easily handled with JavaScript.
The objection regarding bookmarking is irrelevant unless you use no frames all.
Content specific bookmarking can be handled with an "Add Bookmark" JavaScript function
The objection regarding SEO is easily handled by an XML sitemap and JavaScript.
Laying out dynamically sized frames is far easier and more dependable with standard framesets.
Targeting and replacing nested framesets from an external frame is easier with standard framesets.
In-house scripts like JavaScript searches and non-server dependent shopping carts that are too complex for cookies don't seem possible with iFrames, or if they are, it's way more hassle to get them working than using standard frames.
All that being said, I like the single page appeal of iFrames, and when they can actually do all the same stuff for my site as easily as standard frames does now, then I'll migrate. In the meantime, this nonsense about them being "obsolete" is as irksome as the other so-called "upgrades" they've foisted on us over the years without thinking it all the way through.
So what does all this boil down to for the question of whether or not to use framesets? The answer is that it all depends on what you want your site to do and on what platform it will mostly be viewed on. At some point it becomes impractical to make a multi-page site work well without some frames or iFrame integration. However if you're just creating a basic profile page that displays well on a cell phone or tablet, don't bother with framesets.
They almost always make people angry. What more do you need?
Frames are really useful in some occasions. If you are creating a local webpage that serves only for reading, no interactivity involved and the website will not be public on the internet, all the reasons on not to use frames are removed. For example a user manual for an application that is developed solely in html, frames are really useful in keeping a table of contents on the left in a simple and easy to code way. Also if you have proper navigation within the website then the back button ambiguity is removed completely

Are there any alternatives to recaptcha.net, for stopping spam? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
A member of my company in greater ranking than myself refuses to use recaptcha.net on his website to thwart spam off of a public form. He thinks it would be difficult for anyone coming to our site to enter their information since the Turing Tests are "so darn hard to read".
Is there an alternative to using this method? That doesn't contain these sorts of difficult to read images?
(Okay stupid question...if it were up to me we'd use recaptcha because everyone else on earth does...but I just figured I'd check anyway.)
Also, is using a hidden field that is set by Javascript and later checked on the server really a good way to thawart spam?
I myself don't really buy that it is...since there are all sorts of Javascript engines that don't run in a browser yet can run Javascript (Rhino etc...), that could easily be used to thawart a JS/Serverside anti-spam method.
CAPTCHA will reduce your spam but it won't eliminate it. People are paid to decipher those glyphs. Some sites use the glyph that was presented to them for their own site so some hapless visitor will decipher it.
Just so you're aware that it's not a perfect solution.
Based on the principle of don't solve a problem until it's a problem: is spam a significant problem on your website? There is something to be said for not annoying your customers/visitors. Even here I sometimes need to make a few edits and I get the irritating "I'm a Human Being" test on typically the last edit I need to make. It's annoying.
People have proposed all sorts of other methods for dealing with this problem. One I read about used picutres of cats and dogs that you had to classify because apparently there's a database of 30+ million of these in the US for abandoned animals or somesuch. This or anything that gets in widespread use will be defeated.
The biggest problem with spam on sites is if you use software that's in widespread use (eg phpBB). Your best bet for those is to make enough modifications to defeat out-of-the-box scripting. You may get targeted anyway but spamming is a high-volume low-success game. There's no real reason to target your site until it accounts for a significant amount of traffic.
The other thing worth mentioning is techniques that can be used to defeat scripted spam:
Use Javascript to write critical content rather than including it as static HTML. That's a lot harder to deal with (but not impossible);
Rename and/or reorder key fields like username and password. For example, generate username and password form fields and store them as session variables so they only work for that user. That then requires the user to have visited the page with the login form (rather than scripting a form response that can be POSTed directly);
Obfuscate the form submission. Things like unobtrusive Javascript that you can do in jQuery and similar frameworks make this pretty easy;
Include a CAPTCHA image and field box and then don't display them (display: none in CSS). You'll confuse parsers.
The best way for not so popular sites is to insert a hidden field and check it. If it's filled then it's spam because those bots just fill in any field they find.
You might want to look into Akistmet and/or Mollom.
Add a non-standard required input field. For example, require a check-box that says "check me" to be checked. That will defeat any automated scripts that aren't tailored to your site. Just keep in mind it won't defeat anyone specifically targeting your site.
A simple way is to display an image reading "orange", and asking users to type that.
Yes, recaptcha will cut spam but it will also cut conversions! You should consider using XVerify which does real time data verification. What makes those registrations spam is bogus data, with XVerify it will make sure the information you put in is real data by verifing the email address, phone number, and physical address of users. If the information is fake the user cannot click continue! SIMPLE!
I used to think CAPTCHAs were good and used reCAPTCHA on public forms. I noticed that spam submissions were gone but I also noticed that real submissions were cut drastically as well.
Now I don't believe in CAPTCHAs. They work but I feel they can do more harm than good. After having to enter in hard to read CAPTCHAs on other sites I understand why I don't get as many real submissions. Any input that a user must act on that is not related to their main goal is a deterrent.
I usually use several methods to prevent spam and it depends on what type of content I'm expecting in forms. I created server methods that scan comments and mark them as spam based on content. It works ok, but I'm no spam expert so it doesn't work great. I wish someone would make a web service that did this.
I think the links from Evan are pretty interesting!
Another method that I have heard about, which basically extends the javascript idea, is getting the client's browser to perform a configurable JavaScript calculation.
It has been implemented in the NoBot sample as part of the Microsoft AJAX Control Toolkit
http://www.asp.net/AJAX/AjaxControlToolkit/Samples/NoBot/NoBot.aspx for some more details of how it works.
I found an alternative called Are You A Human. Not that programmers should go on gut feelings, but from the start it seemed insecure. Since it's a fun game you play, I decided to try it. It didn't work for me. It's possible the host isn't set up for it. That's the last thing for me to check.
If anyone else has tried ayah, I'd like to know how it worked.
I've used Confident Captcha before and it was really easy to get set up and running. Also I haven't had any spam get through on the forum I manage.
It isn't a text based Captcha but instead uses images similar to picaptcha. I've tried 'Are you a human' before and it's definitely an interesting concept.
Found one called NuCaptcha which displays moving letters...
8 years later...
I have been looking for alternatives to Google's reCaptcha, which doesn't ruin the UX, tracks user, etc. and found this gem: Coinhive Captcha.
It works by mining Monero coins (hash count is adjustable) in the background and provides a server-side API to verify it. It should be noted, that - depending on the selected hash count to solve - it may be slow, specially on mobile devices.