Impressive Webs http://www.impressivewebs.com Web Design Articles & Tutorials. To make the web impressive. Thu, 03 Sep 2015 06:48:25 +0000 en-US hourly 1 http://wordpress.org/?v=4.2.4 CSS Positioning Basics (Screencast) http://www.impressivewebs.com/css-positioning-basics-screencast/ http://www.impressivewebs.com/css-positioning-basics-screencast/#comments Thu, 23 Apr 2015 12:57:26 +0000 http://www.impressivewebs.com/?p=14650 A couple of years ago I wrote an article for a company called Thinkful on CSS positioning, which also included a screencast that I hosted on my ImpressiveWebs YouTube channel. The video was "unlisted" but I've now made it public, and since some time has passed I thought I would post the video here. It's pretty basic stuff for most experienced CSS developers, but if anyone wants a quick primer on CSS positioning, this should be a good guide. The video is embedded below and I've summarized the content here in this post.]]> A couple of years ago I wrote an article for a company called Thinkful on CSS positioning, which also included a screencast that I hosted on my ImpressiveWebs YouTube channel. The video was “unlisted” but I’ve now made it public, and since some time has passed I thought I would post the video here.

It’s pretty basic stuff for most experienced CSS developers, but if anyone wants a quick primer on CSS positioning, this should be a good guide. The video is embedded below and I’ve summarized the content here in this post.

Some main points from the screencast:

  • The position property in CSS takes 4 common values supported in all browsers. There are other values, but this video only deals with the well supported ones.
  • In order to position something with the top, right, bottom, and left values, you need to set the element to either “position: absolute” or “position: relative”.
  • If a child is absolutely positioned, it will be positioned relative to the viewport or the closest relatively positioned parent.
  • You can make an element automatically expand to fit its relative parent by using “0” values for all the offsets.
  • Static elements will ignore an absolutely positioned element, behaving as if it’s not there. Because of this, absolute positioning is not recommended for large layout features or other areas of your site that are dependent on the natural flow of elements.
  • CodePen demo used in the screencast.
]]>
http://www.impressivewebs.com/css-positioning-basics-screencast/feed/ 13
My Talk and Slides from FITC Toronto 2015 http://www.impressivewebs.com/my-talk-slides-from-fitc-toronto-2015/ http://www.impressivewebs.com/my-talk-slides-from-fitc-toronto-2015/#comments Tue, 21 Apr 2015 10:00:30 +0000 http://www.impressivewebs.com/?p=14635 On Tuesday, April 14, I had the privilege of speaking at FITC Toronto 2015, a technology and creativity conference that features events all around the globe, many of them in Canada. It was my second talk ever, and it seemed to go over pretty well. This was a 4-track conference, so it was nice to see a packed room with standing-room only (or so they told me — as you can see from the video below, those lights blind the speaker to what's going on in the room!). My talk was focused on the tools explosion that we've seen in the front-end development industry in the past 5 years or so. If you've been following my tools newsletter for some time, then you would have seen some, if not most, of the stuff in the talk. But I did go in depth on a few of the tools that I featured, so there should be something new in here for most front-end developers.]]> FITC Toronto 2015On Tuesday, April 14, I had the privilege of speaking at FITC Toronto 2015, a technology and creativity conference that features events all around the globe, many of them in Canada. It was my second talk ever, and it seemed to go over pretty well. This was a 4-track conference, so it was nice to see a packed room with standing-room only (or so they told me — as you can see from the video below, those lights blind the speaker to what’s going on in the room!).

My talk was focused on the tools explosion that we’ve seen in the front-end development industry in the past 5 years or so. If you’ve been following my tools newsletter for some time, then you would have seen some, if not most, of the stuff in the talk. But I did go in depth on a few of the tools that I featured, so there should be something new in here for most front-end developers.

Due to the nature of the event (being a fairly general, non-niche conference), I had a feeling there would likely be many in the audience who found the material a little over their heads. I tried to keep it as simple as possible but, to be honest, many of the tools I talked about are over my head, too!

Below you’ll find the FITC video, my slide deck, along with the full list of links to the stuff referenced in the talk.

Note: Choose one of the “HD” settings for the video, if it’s not already selected. This will help you to see the code examples a little more clearly.

Intro / Bio

The Usual Suspects

HTML, CSS, and Sass Tools

JavaScript Tools

Text Editors and More

Keeping Up and Learning

]]>
http://www.impressivewebs.com/my-talk-slides-from-fitc-toronto-2015/feed/ 0
How to Write Great Web Development Articles and Tutorials http://www.impressivewebs.com/how-to-write-great-web-development-articles-tutorials/ http://www.impressivewebs.com/how-to-write-great-web-development-articles-tutorials/#comments Wed, 18 Mar 2015 11:00:03 +0000 http://www.impressivewebs.com/?p=14549 Pen and PaperAs some of you probably already know, since January 2014 I’ve been working for SitePoint as one of their Managing Editors, mostly editing HTML, CSS, and Sass content. I’ve also helped out with Mobile content, JavaScript, some general Web stuff (Git articles, build tools, and other generic content), and I write SitePoint’s primary newsletter each week.

I love my job at SitePoint—it’s the best job I’ve ever had. As long as SitePoint still wants me working for them, I hope I can continue to help them put out better and better content for front-end developers.

I’ve rejected or sent back for editing quite a few articles since I’ve started my editing duties. Many of those rejections suffered from the same problems. So for this post, I’ve put together my thoughts on what I think makes for a good web development article or tutorial.

]]>
As some of you probably already know, since January 2014 I’ve been working for SitePoint as one of their Managing Editors, mostly editing HTML, CSS, and Sass content. I’ve also helped out with Mobile content, JavaScript, some general Web stuff (Git articles, build tools, and other generic content), and I write SitePoint’s primary newsletter each week.

I love my job at SitePoint—it’s the best job I’ve ever had. As long as SitePoint still wants me working for them, I hope I can continue to help them put out better and better content for front-end developers.

I’ve rejected or sent back for editing quite a few articles since I’ve started my editing duties. Many of those rejections suffered from the same problems. So for this post, I’ve put together my thoughts on what I think makes for a good web development article or tutorial.

Some Opening Remarks

Before getting into the meat of this, let’s get a few things out of the way:

  • Not everyone will agree with me on all these points.
  • I’m not writing this because I think I’m better than others. We all have our strengths. I’m not perfect. I could name 100 developer/writers who are better than me.
  • Many of the items in this post are from a document I’ve been compiling for some time now, and which I’ve passed on to authors who write for SitePoint, to help them improve.
  • Many of these tips apply to any kind of writing, not only technology or development.
  • My views in this post do not necessarily represent those of SitePoint or its management. The editors at SitePoint have a lot of freedom to shape the content, but it’s still subject to SitePoint’s guidelines, which might differ from my own as stated here.

With that somewhat dragged-out introduction (more on that later!), let’s get to the main points.

Articles should almost always have reference links. If you’re writing about front-end technologies, your content should generously link to stuff like:

  • W3C Spec
  • MDN’s reference
  • Authoritative articles by respected members of the community
  • Good articles by the same publisher that you’re writing for (preferably not really old ones).

If you’re discussing a particular tool or technology (like a specific jQuery plugin or a CSS Preprocessor), your first paragraph should always link to the home page for that technology. This is especially true if you’re talking about a new tool or technology or one that’s not as well known. In some cases, if the tool is common in context (like Sass on a blog about Sass), then you’re probably fine not including a link to Sass’s home page.

You should also include links to support certain kinds of statements made. For example:

  • “Google considers page speed in SEO rank.”
  • “Studies show people scan websites, they don’t read them.”
  • “Flexbox is supported in IE11.”
  • “Hamburger icons are bad for usability.”

All the statements above (and similar) should be sourced. Especially if you’re talking about a controversial subject where people are going to debate you. Some statements, however, are opinions. If that’s the case (e.g. the 4th point above), then you should clearly state that this is your view, and give reasons why.

As an example, this article on accessibility mentions some case studies. Notice the studies aren’t only discussed; they’re sourced with links.

Related to the point of linking to sources, if you’re talking about specific features in Bootstrap, or Sass, or another tool or framework, you should link to the sections in their documentation that you’re discussing. For example, if you’re talking about Bootstrap’s Jumbotron component, link to it.

Sometimes I get the feeling that authors are afraid to link back to a tool’s docs because they feel they will be “revealing their research secrets”. Maybe I’m wrong, but that’s how it seems.

Linking back to specific parts of documentation helps the reader to have some extra stuff to look into should the need arise. And it shows that you respect the authority of the official docs for that tool, and this gains a reader’s respect.

I’ve made this mistake myself a few times. If you are talking about, for example, Flexbox, you might search for the spec and find a link like this:

http://www.w3.org/TR/2014/WD-css-flexbox-1-20140325/

But that’s a static version of the spec that won’t change. What you want is the permanent link to the current version of the spec. So make sure the URL looks more like this:

http://dev.w3.org/csswg/css-flexbox/

Sometimes, unfortunately, a Google search will bring up a “snapshot” version first. You’ll be able to tell by the URL.

Also, I think the “dev” version (which is usually called the “editor’s draft” of the W3C spec) should be linked to more often than the non-dev version. Usually the differences are small, but the dev version is always more up to date (although it’s also more in flux).

Always Try to Include a Demo

For front-end technologies like HTML, CSS, and JavaScript, there is usually no excuse for not including a demo with whatever you’re talking about. Naturally, there are some cases where a demo is of little value. An article about semantic HTML is one example. A Sass article also may not benefit from a demo.

Believe it or not, I’ve edited articles that included a screenshot of the technique being discussed, but not a demo. That’s kind of like giving someone a picture of a hamburger for dinner!

For demos, some useful tools are:

The last one in that list, SassMeister, can be used when it’s not necessarily a visible demo, but a code concept or technique where you want to see the compiled output.

When coming up with ideas for articles or tutorials, try to go with ideas that will work well with demo pages. Those are often the best and most popular articles.

Include a Brief But Effective Introduction

Too many authors write intros that basically amount to “filler” content. Here’s an example of a bad introduction:

Front-end developers have been trying many different frameworks in recent years. Bootstrap is a really popular framework, and it has many tools you can use today. We no longer need to scratch our heads wondering how to create a cross-browser drop-down menu, or a responsive grid, or a tab switcher. Bootstrap can do it all. But how accessible are its components? In this post, I’ll show you how to take Bootstrap to the next level by making your Bootstrap website more accessible.

Notice all the unnecessary fluff leading up to the main point of the article about accessibility? Instead, the following is better:

Bootstrap is the most widely-used framework in the world. But a common complaint I hear is that its markup is unsemantic and inaccessible. Let’s use two Bootstrap components as examples to see if we can remedy this.

This intro is clear, it presents exactly the problem you’re going to solve, and it gets right into the meat of the post, which is how to make a Bootstrap website (or component) accessible.

In brief, a good intro has two necessary ingredients:

  • Present a problem to solve
  • Tell us briefly how you will solve that problem

Then get right into it. Chris Coyier of CSS-Tricks is the master of introductions. He doesn’t waste any time, he immediately tells you what problem he’s facing and how he’s going to consider solving it. This recent post is a perfect example of that. No rambling, no wasting time, straight to problem/solution.

Write Tool/Technology Names in the Correct Format

Sometimes it feels like 90% of my edits are correcting “JQuery” to “jQuery”; “SASS” to “Sass”; “Github” to “GitHub”; or “AJAX” to “Ajax” (believe it or not, it’s not an acronym!). This is especially necessary if you’re talking about an obscure technology or a new tool by a startup that’s trying to establish a brand.

Do the necessary research. Take five seconds to look at the official website or GitHub repo of the tool you’re discussing and make sure you get the casing and/or spacing right. If MailChimp calls itself “MailChimp”, don’t write it as “Mail Chimp”, “mailchimp”, or “Mailchimp”. In some cases, even the official website itself will use different casing for the name of the technology. If that’s the case, I usually pick the one that’s in the website’s title element.

By writing tool names properly, in the way the creators intended, we show respect for these tools and we help to represent their brands correctly in our writing.

Don’t Try to Sound Professional or Formal

The best articles are the ones where the author talks to the readers in his/her own voice. Imagine you’re having a conversation with your good friend at a web conference. You would never say something like this:

“Flexbox has numerous features that developers can avail themselves of in order to help their layouts be on the cutting edge and avoid legacy practices.”

That’s not too inviting. Instead you would say something more natural, like:

“We’ve used Float and positioning hacks for years in older browsers. Flexbox makes all of that so much easier.”

Of course, there’s balance needed here. You don’t want to sound so informal in your writing that your readers are annoyed. Keep it loose and be yourself, but don’t be too crazy.

Also, try to avoid pretentious Shakespearean-sounding words like “whilst” or “hence”. I know that some of these words are common in certain parts of the world, but remember that on the web you’re writing for a larger audience, so “whilst” can always be replaced with “while”, and “hence” can be replaced by something less-pretentious like “therefore”.

Similarly, I’ve never found a sentence that benefited from the expression “the former… and the latter”. For example:

CSS and HTML have been around for years. The former for 20 years; the latter for 24.

This former/latter expression is irritating to read, especially in a more complex sentence. The following is easy enough to write and understand:

CSS has been around for 20 years and HTML has been around for 24.

As mentioned, it’s all about simplifying and asking yourself “Would I say this in a face-to-face conversation?” If the answer is “no”, then you might want to rework the sentence. But again, this doesn’t mean you should write like you talk. It should be natural and conversational, but a little more formal than your everyday speech.

A Hyphen is Not the Same as a Long Dash

There are a lot of general writing and grammar tips like this one that I could include in this post, but I feel like this is the one that people most commonly get wrong. The following is not correct:

Sass is a great technology ‐ albeit a difficult one to learn.

This is correct:

Sass is a great technology — albeit a difficult one to learn.

Hyphens are used for math, phone numbers, breaking words onto new lines, in compound words (e.g. “accident-prone” or “five-column grid”), and so on. But they shouldn’t be used at the start of an interjection in a sentence. That’s where you need a long dash. You can copy and paste a real long dash (—), or you can use the character entity, —. Also, most style guides recommend no spaces before and after the long dash, although apparently it’s not a hard-and-fast rule.

On a related note, you might want to read through this Bootstrap issue where a similar topic was discussed, showing the proper use of a hyphen and the two kinds of dashes.

Headings Alone Should Develop the Theme

A reader should be able to read the title of your post, then read each of the primary headings in order, and get a good higher-level understanding of the subject being discussed.

To do this, your headings should be clear in stating which part of the article is now being developed and they should not be general or vague.

Imagine you were about to read an article on making a Bootstrap site accessible. Here is an example of bad headings:

<h1>How to Make Bootstrap Accessible</h1> 
  <h2>Why?</h2>
  <h2>Suggestion #1</h2>
  <h2>Suggestion #2</h2>
  <h2>Suggestion #3</h2>
  <h2>Conclusion</h2>

The headings in that example tell you nothing about how the content will be developed. Here’s the same example improved:

<h1>How to Make Bootstrap Accessible</h1>
  <h2>Why is Bootstrap Inaccessible?</h2>
  <h2>Use ARIA Roles</h2>
  <h2>Use Semantic Tags</h2>
  <h2>Use WAVE to Test Accessibility</h2>
  <h2>Conclusion</h2>

Now the content being discussed is much more clear and inviting.

On a similar subject, you don’t need a heading called “Introduction”. Your introductory text will be the introduction. You’ll notice that my “improved” example above includes a heading called “Conclusion”, which is just as vague as “Introduction”. But that’s okay. This serves as a signal that the article is coming to an end, so I think it has some value.

Don’t Say Things Like “It’s Easy” or “It’s Very Good”

If something is “easy” or “very good” your readers will decide based on the evidence you present. Not everyone is at the same level. If you’re writing an article about the command line, and you say stuff like “It’s easy, simply type git [whatever]”, you’re going to alienate many readers.

Even the simplest CSS and HTML topics are not “easy” to some people. So avoid sentences like that. This is true in a lot of other cases too. Here are some examples of bad ways to write things:

Bad:

Git is an easy tool to use to assist with version control.

You don’t have to tell the reader it’s easy; instead, explain why it’s easy. In other words, describe in detail what makes it easy, but don’t tell them that.

Another bad example:

Bootstrap is powerful and useful.

That sentence says nothing. Instead, say something like this:

Bootstrap can help you get any project off the ground fast, and in a cross-browser fashion.

In many cases I see authors writing both of the above sentences, one after the other. You don’t need the first one. The reader will see the “power” and “usefulness” in the explanation itself. And what if the user doesn’t think it’s “useful” or “powerful”, even after that explanation? Well, that’s up to them.

But balance is needed here too. You can tell readers you love something or that it’s cool, but say it in a context where it has some value, otherwise it amounts to nothing but filler.

Avoid Vague Words Like “very” and “really”

Further on this point, 99% of articles could do a find-and-replace on all the following words and it likely wouldn’t change anything about the article:

  • very
  • really
  • just
  • literally
  • honestly
  • actually
  • certainly
  • absolutely
  • surely
  • truly
  • in fact
  • simply

But again, balance is needed. Sometimes these words can serve as a way to make things a little more natural and conversational. But don’t overuse them (especially the first three). In almost all cases, you don’t have to say how “very useful” something is; instead, tell your readers why it’s useful.

Don’t Alternate Between “we” and “you”

In a tutorial, you might be talking the user through a series of steps. So you might say something like:

“We will put the HTML tag in here with a custom class”.

But later in the article you might say:

“You can remove that class now.”

Notice how you’ve switched the viewpoint? If you start out talking about what “we” are doing, stay with “we”; don’t switch to “you”. I’ve even seen this switch take place in the same sentence!

We will put the HTML tag here because you want it accessible.

So be consistent:

We will put the HTML tag here because we want it accessible.

Have Consistent and Easy-to-Read Code Blocks

When including code blocks in articles and tutorials, I have a few general rules:

  • No horizontal scrolling
  • Consistency in syntax and whitespace
  • No single line CSS

The following is a bad example of a CSS code block:

.example{
  float:left;
  color:blue;
}

It’s subtle, but here is the same example corrected:

.example {
  float: left;
  color: blue;
}

The difference might not be significant in the above comparison, but it’s much more clear when using multiple code examples on a single page, with longer code blocks. So don’t forget the space after the colon for property/value pairs, as well as the space after the selector and before the opening curly brace.

Further on this, I don’t like CSS that looks like this:

.example
{
  float: left;
  color: blue;
}

Always put the opening brace on the same line as the selector. This should be done in JavaScript too, in function syntax.

As mentioned, don’t do single-line CSS, always use multi-line code blocks. Even if you prefer single-line in real projects, that’s fine. They’re not wrong to use in production. But they are not as readable in tutorials and articles, so always use multi-line CSS blocks.

In line with the no horizontal scrolling rule, try to avoid overly long lines of code. So let’s say you have the following HTML:

<link rel="apple-touch-icon-precomposed" sizes="114x114" href="/images/apple-touch-icon-114x114-precomposed.png">

You can improve the readability of that by writing it like this:

<link rel="apple-touch-icon-precomposed"
      sizes="114x114"
      href="/images/apple-touch-icon-114x114-precomposed.png">

You can do something similar with long selector groups or long CSS transition declarations. So instead of this:

.example, example2, .example3, .example4, .example5, .example 6, .example7, .example8 {
  transition: color 3s linear, width 2s ease-out, height 3s ease-in, border-width 1s linear;
}

You can do this:

.example, example2,
.example3, .example4,
.example5, .example 6,
.example7, .example 8 {
  transition: color 3s linear,
              width 2s ease-out,
              height 3s ease-in,
              border-width 1s linear;
}

No Walls of Code

If any code block is longer than 10 or 15 lines, then you’re probably doing something wrong. To fix this, you can try one of the following:

  • Remove any unnecessary parts of the code. I can’t count the number of times I’ve removed the “doctype” from a code block. Not to mention other things like an entire <head> section, which might include meta tags and other elements that had nothing to do with the article.
  • If you’re talking about one specific CSS feature, don’t include all the styles you apply to the element being affected with that feature. For example, when talking about transitions, only include the transition property along with some other relevant stuff (like the properties you’re transitioning). Don’t include stuff like “float: left” or “margin: auto” that have nothing to do with the transition. Tell the reader that common CSS is removed for brevity and only include the necessary code.
  • If, for whatever reason, your code must be lengthy, then you can add a bullet list below it to describe what’s happening step by step.
  • If possible, break the code block up, discussing it in steps, then (if you must) include the completed code at the bottom of the section or article, and indicate clearly that this is the completed piece, with any relevant demo or code hosting links.

The Best Article Topics are Specific

Articles that are popular and easy to follow are ones that are specific rather than overly general. Here are some examples of article/tutorial ideas that are far too general and are likely not going to be too popular:

  • Building a Website with Foundation 5
  • An Introduction to Git
  • Building a Responsive Website with jQuery Mobile

Those are decent ideas, but unless they are comprehensive and well written, they are likely not going to get much traffic or generate much buzz.

Here are some better ideas:

  • How to Create Off-canvas Navigation with Foundation 5
  • Installing Git on Windows, Linux, or Mac
  • Understanding jQuery Mobile’s Responsive Grid

You can see that all three of the ideas are related to the previous three, but are more specific. So these topics don’t offer the kitchen sink, so to speak (which is difficult to do well) but rather, they focus on a single aspect of the subject at hand, which will be much easier to present in an effective way and will, as a bonus, be much more likely to gain SEO value.

Conclusion

As already mentioned, I’m far from the perfect writer. But after blogging regularly for about 6 years now and editing 3-4 articles per week for over a year, I feel I’ve gained some insight into what readers like and what they don’t like, what works and what doesn’t work.

I hope some of what I’ve written here can help other writers trying to produce content that people in the industry will be interested in reading and sharing. There’s no single recipe for success, but I think the above tips can serve as a kind of general template for successful articles.

]]>
http://www.impressivewebs.com/how-to-write-great-web-development-articles-tutorials/feed/ 29
A JavaScript & DOM E-Book Offer http://www.impressivewebs.com/javascript-dom-e-book-offer/ http://www.impressivewebs.com/javascript-dom-e-book-offer/#comments Mon, 09 Mar 2015 12:19:06 +0000 http://www.impressivewebs.com/?p=14510 As many of you know, I publish a weekly newsletter called Web Tools Weekly that's now gained a pretty nice subscriber base of over 10,000. In addition to the weekly list of categorized tools, each issue usually starts with a brief tutorial or tip, usually something focused on JavaScript and the DOM. After 80+ issues, I've amassed quite a bit of JavaScript- and DOM-focused content. All of that content is available for free in the Web Tools Weekly archives. However, for those who would like to read the tips on a tablet or mobile device, I thought it would be useful to put it together in book form in PDF, EPUB, and MOBI formats. So I've just released JavaScript & DOM Tips, Tricks, and Techniques, a collection of 70 tips (125+ pages in PDF), priced at $5.]]> As many of you know, I publish a weekly newsletter called Web Tools Weekly that’s now gained a pretty nice subscriber base of over 10,000. In addition to the weekly list of categorized tools, each issue usually starts with a brief tutorial or tip, usually something focused on JavaScript and the DOM.

After 80+ issues, I’ve amassed quite a bit of JavaScript- and DOM-focused content. All of that content is available for free in the Web Tools Weekly archives. However, for those who would like to read the tips on a tablet or mobile device, I thought it would be useful to put it together in book form in PDF, EPUB, and MOBI formats. So I’ve just released JavaScript & DOM Tips, Tricks, and Techniques, a collection of 70 tips (125+ pages in PDF), priced at $5.

JavaScript & DOM Tips, Tricks, and Techniques

The tips in the book appear in the same order as they’ve appeared chronologically in the newsletter each week. Although the book was produced through Leanpub, I’m not promoting it for sale via that channel. Leanpub is pretty flexible, so I’m selling it via Pulley, which is an inexpensive and super-simple service for selling digital goods. You can purchase it through Leanpub if you want, but that’s not my preferred channel.

The book uses Leanpub’s default settings for technical material, so it’s very reader-friendly and the code highlighting is really nice. Below is a screenshot from the PDF:

JS & DOM E-Book PDF

And here is one from the EPUB on iOS using scrolling view:

JS & DOM E-Book EPUB

Like I said, all of the content in this e-book is available for free online on the Web Tools Weekly website (aside from some minor corrections and improvements), so the material isn’t new but it’s just packaged in an easier to read format for offline viewing.

Below are the links for the full description of the content and the direct purchase:

  • JavaScript & DOM Tips, Tricks, and Techniques E-Book (info page with table of contents)
  • Buy it now for $5
    • I’ll continue to publish similar tips in the newsletter in the weeks ahead, but if you’re interested in getting all the past tips in one package, it’s all here.

      ]]> http://www.impressivewebs.com/javascript-dom-e-book-offer/feed/ 0 Displaying Your MailChimp Subscriber Count with PHP and MailChimp’s API http://www.impressivewebs.com/displaying-mailchimp-subscriber-count-php-mailchimp-api/ http://www.impressivewebs.com/displaying-mailchimp-subscriber-count-php-mailchimp-api/#comments Wed, 22 Oct 2014 12:14:41 +0000 http://www.impressivewebs.com/?p=13809 MailChimp logoAs many of you probably know, I’ve been writing a weekly newsletter called Web Tools Weekly for over a year now. Most issues begin with a brief JavaScript tutorial, after which I include a curated list of tools primarily focused on front-end development. I’ve released a new issue every week, without a break, since July 2013 and I use MailChimp to produce the mailing (disclosure: previous link has my affiliate ID attached, which means we both get $30 towards MailChimp if you become a paying customer).

      The subscriber count has grown to almost 10,000 as of this writing, and that number is growing by about 70 each week. For the past couple of months, I’ve been displaying the subscriber count on the home page, and manually editing it every once in a while.

      ]]>
      MailChimp logoAs many of you probably know, I’ve been writing a weekly newsletter called Web Tools Weekly for over a year now. Most issues begin with a brief JavaScript tutorial, after which I include a curated list of tools primarily focused on front-end development. I’ve released a new issue every week, without a break, since July 2013 and I use MailChimp to produce the mailing (disclosure: previous link has my affiliate ID attached, which means we both get $30 towards MailChimp if you become a paying customer).

      The subscriber count has grown to almost 10,000 as of this writing, and that number is growing by about 70 each week. For the past couple of months, I’ve been displaying the subscriber count on the home page, and manually editing it every once in a while.

      Web Tools Weekly subscriber count

      Clearly, that’s not an ideal method for doing this sort of thing – especially when MailChimp offers an API that lets you tap into your numbers and do all sorts of other stuff programmatically.

      So I did some research on how to get the subscriber count to display automatically on the Web Tools Weekly home page and here’s what I came up with.

      MailChimp API by Drew McLellan

      The only back-end language I know how to work with on my own is PHP (and I use the phrase “know how to work with” very loosely!). Taking a quick look at MailChimp’s API docs shows that they have listed various API abstraction tools, including some for PHP.

      This led me to try out Drew McLellan’s MailChimp API (Drew is the 24 ways guy, in case you’re trying to figure out why you know that name).

      Drew’s script is great because it’s simple. It gives you an easy interface into the data available, then you can just mess around with it from there to get what you want.

      After including the source file from Drew’s script, I modified it slightly to use my own custom namespace (i.e. I changed “Drewm” to “WTW”) and then I used his example in the docs to instantiate the main object:

      include "vendor/MailChimp.php";
      $MailChimp = new \WTW\MailChimp('[api key]');
      $mc = $MailChimp->call('lists/list');
      

      In that first line, you would replace “[api key]” with your actual API key from MailChimp. You can use this guide from MailChimp to create your key and include it when using Drew’s (or anyone else’s) script.

      Once I had the object instantiated, I had no idea what the actual API consists of. So after some fiddling with PHP’s var_dump and print_r, I was able to come up with the following line of PHP to produce the number of subscribers:

      $curr_sub_count = $mc[data][0][stats][member_count];
      

      Once I have that, I can display the $curr_sub_count variable anywhere on the page, and this would show an updated subscriber count that I don’t need to manually change every week.

      Limiting Calls to the API

      At this point, the main problem with this code is the fact that I’m connecting to the API on every page load. MailChimp’s API has some limitations that might cause problems if the Web Tools Weekly website got a traffic spike.

      All that I need to do is access the API once per day, record that value somewhere, and then use it in the page as needed. So I Googled around a bit and found this StackOverflow thread. The top-rated answer (not the one that’s checkmarked) produced the following code:

      $lastRunLog = 'vendor/lastrun.log';
      $subfile = 'vendor/subcount.log';
      $lastRun = file_get_contents($lastRunLog);
      
      if (time() - $lastRun >= 86400) {
          // its been more than a day so we can connect to the API
          $MailChimp = new \WTW\MailChimp('[api key]');
          $mc = $MailChimp->call('lists/list');
          $curr_sub_count = $mc[data][0][stats][member_count];
          // update lastrun.log with current time
          file_put_contents($lastRunLog, time());
          file_put_contents($subfile, $curr_sub_count);
      } else {
          $curr_sub_count = file_get_contents($subfile);
      }
      

      Here’s a summary of what’s happening in that script:

      • The first two lines are referencing log files that I’ve placed on the server inside of a folder called “vendor”. The lastrun.log holds the time the API was last accessed, in a Unix time stamp.
      • The second log file is called subcount.log. This is where I record the subscriber count.
      • Next I grab the contents of the log, then I check to see if it’s been 24 hours since the last time the API was accessed. The number 86400 is used because that’s exactly 24 hours in Unix time, as explained in this thread.
      • If it has been 24 hours since the last API call, we run a new API call to get the new subscriber count, record the current time into lastrun.log, and update the count in subcount.log.
      • If it’s been less than 24 hours, the “else” branch is used, and we simply get the count from the subcount.log file without doing an API call.

      In the HTML for the Web Tools Weekly home page, I have a line that looks like this:

      <p class="sub">Join <?php echo number_format($curr_sub_count); ?> subscribers!</p>
      

      This uses PHP’s number_format() function to make the count appear with a comma (i.e. “9,478” instead of “9478”).

      And that’s it. With this chunk of code in place, I’m ensuring the API is not being unnecessarily queried. If the subscriber count changes only slightly, or not at all, in any given hour, then clearly there’s no need to connect to the API each time the page is visited. Even once a day is probably unnecessary with only about 10 new subscribers per day, but I think this is a more reasonable approach.

      Other Techniques?

      If you have any suggestions for any of the code above or if you have used MailChimp’s API for something similar, but using a different method, I’d love to hear your thoughts.

      ]]>
      http://www.impressivewebs.com/displaying-mailchimp-subscriber-count-php-mailchimp-api/feed/ 20
      onchange vs. oninput for Range Sliders http://www.impressivewebs.com/onchange-vs-oninput-for-range-sliders/ http://www.impressivewebs.com/onchange-vs-oninput-for-range-sliders/#comments Tue, 14 Oct 2014 10:00:02 +0000 http://www.impressivewebs.com/?p=13766 Free range eggsA common UI pattern for a range slider is to allow the user to move the slider and display the value of it somewhere on the page, changing the displayed value as the user moves the slider.

      I think the expected behaviour in such a case is that the value should display instantly, as the user is moving the slider, rather than the page waiting for the slider to finish moving before the displayed value is updated. I suppose there could be cases where you prefer a delay over instant results, but I think the expected behaviour is to display the results instantly.

      As you’ll see in the videos below and in your own testing, the behaviour of the input event compared to the change event is not exactly the same in different browsers when applied to a range slider.

      ]]>
      A common UI pattern for a range slider is to allow the user to move the slider and display the value of it somewhere on the page, changing the displayed value as the user moves the slider.

      I think the expected behaviour in such a case is that the value should display instantly, as the user is moving the slider, rather than the page waiting for the slider to finish moving before the displayed value is updated. I suppose there could be cases where you prefer a delay over instant results, but I think the expected behaviour is to display the results instantly.

      As you’ll see in the videos below and in your own testing, the behaviour of the input event compared to the change event is not exactly the same in different browsers when applied to a range slider.

      Let’s look at how these events behave in the different browsers. The code I’ll be using is embedded in the JS Bin example below:

      JS Bin

      Swap change with input to see the differences I’ll be discussing. The results described are observed on OSX and Windows 7.

      Note: Opera is equivalent to Chrome in these tests because it now has the same rendering engine.

      oninput in Chrome

      Observations:

      • Works as expected, the input event fires immediately when the slider is adjusted, which is demonstrated by the value changing on the page instantly.
      • Focusing and adjusting the slider with the keyboard has the same result.

      onchange in Chrome

      Observations:

      • The change event does not fire immediately, demonstrated by the fact that the value on the page does not change until the slider stops moving.
      • Keyboard interaction, however, is the same as oninput, with the value on the page updating immediately.

      oninput in Firefox

      Observations:

      • Same results as oninput in Chrome; changes happen immediately.
      • Keyboard results the same, changes appear immediately.

      onchange in Firefox

      Observations:

      • Same results as Chrome; the value doesn’t change on the page until the slider stops moving.
      • When moving the slider with the keyboard, the value does not update until the slider is blurred, or unfocused. This is the only difference from the behaviour in Chrome.

      oninput in IE11

      Observations:

      • oninput is not recognized at all when used on a range slider. The same event, however, does fire when used on a text input.
      • Although oninput doesn’t fire, the value of the slider is displayed in a native tooltip, which doesn’t happen on the other browsers.
      • The keyboard likewise has no effect on the value and the native tooltip is not displayed.

      onchange in IE11

      Observations:

      • Works the same way as oninput in Chrome and Firefox; the value changes immediately while the slider is still moving.
      • Keyboard results are the same, the value updates immediately.

      What’s the Correct Behaviour?

      The WHATWG spec describes the expected behaviour as follows:

      The input event fires whenever the user has modified the data of the control. The change event fires when the value is committed, if that makes sense for the control, or else when the control loses focus. In all cases, the input event comes before the corresponding change event (if any).

      The same description is found in the W3C version of the spec.

      For oninput, Chrome and Firefox have the correct behaviour with both mouse and keyboard interaction. But Firefox seems to have the most accurate behaviour for onchange.

      As shown in the quote above, onchange should always fire after oninput, so the fact that Firefox waits for the range slider to lose focus before firing the event (for both mouse and keyboard) seems to be the correct behaviour. Chrome does not wait until the control is unfocused when using the keyboard, but it does so with the mouse.

      IE11, of course, is completely wrong on two counts: It doesn’t recognize oninput when applied to a range slider and it responds to onchange as if it was oninput, firing the event immediately instead of waiting until the slider stops moving or loses focus.

      As a side point here, the HTML4 spec seemed to define the behaviour a little more clearly:

      The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus.

      Though when that was written, there was no such thing as type="range" for form inputs.

      Sources and Bug Reports

      There has been discussion on this behaviour in the bug trackers for the various browsers, and I believe the wording in the spec was updated to be less ambiguous — although I still feel that it’s not 100% clear if Firefox’s keyboard behaviour is the correct one.

      Here are some relevant links in addition to the ones provided in the article above:

      • Firefox bug report – Closed as “invalid” since Firefox’s behaviour is correct.
      • IE11 bug report on missing input event, still unresolved.
      • Chrome bug report which I filed myself to see if the different keyboard behaviour can be corrected to agree with Firefox.
      • W3C bug report, which attempts to make the spec less ambiguous.
      • change event on MDN, which explains that “different browsers do not always agree whether a change event should be fired for certain types of interaction.”
      ]]>
      http://www.impressivewebs.com/onchange-vs-oninput-for-range-sliders/feed/ 4
      Frontend RSS Feeds Revisited http://www.impressivewebs.com/frontend-rss-feeds-revisited/ http://www.impressivewebs.com/frontend-rss-feeds-revisited/#comments Mon, 02 Jun 2014 17:34:55 +0000 http://www.impressivewebs.com/?p=13062 Back in 2008, Paul Irish posted a modest list of RSS feeds for front-end developers to follow. Since that original post, he's updated the list multiple times, and his list is now on GitHub growing to over 200 feeds. It looks like the list hasn't been updated in 6 months or more. Not a really big deal, but I noticed when I imported the OPML into my feed reader, there were a number of broken feeds, empty feeds, and feeds not updated in quite some time. For a while now I've wanted to put together my own list of front-end feeds, so here it is.]]> Frontend RSS Feeds RevisitedBack in 2008, Paul Irish posted a modest list of RSS feeds for front-end developers to follow. Since that original post, he’s updated the list multiple times, and his list is now on GitHub growing to over 200 feeds.

      It looks like the list hasn’t been updated in 6 months or more. Not a really big deal, but I noticed when I imported the OPML into my feed reader, there were a number of broken feeds, empty feeds, and feeds not updated in quite some time.

      For a while now I’ve wanted to put together my own list of front-end feeds, so here it is.

      Some of the things I’ve focused on for this list are:

      • Not too many overly technical feeds that most of us don’t benefit much from (standards bodies, browser makers, etc.)
      • I’ve included CSS/HTML/JS category feeds for many design blogs that don’t post a lot of code. These won’t always be the most high quality feeds, but I think they have some value.
      • I’ve ensured that, as of this writing, almost all the feeds included are updated fairly regularly, or else they have been updated in the past 6 months.

      If you have any suggestions for stuff to add, even if it’s your own blog/website, feel free to submit a pull request or open an issue on GitHub and I’ll see what I can do. I’m only accepting feeds that are based on front-end development.

      So to sum up, in no way am I trying to make a “better” list than Paul’s. His is still great, and I’m sure many will continue to use it. I just thought the community needed a more intermediate-ish list of resources for our daily/weekly reading.

      Enjoy!

      For reference, you can find Paul’s feed list here.

      ]]>
      http://www.impressivewebs.com/frontend-rss-feeds-revisited/feed/ 13
      Cursor-Over-Text Behaviour in Browsers http://www.impressivewebs.com/cursor-over-text-behaviour-browsers/ http://www.impressivewebs.com/cursor-over-text-behaviour-browsers/#comments Fri, 21 Mar 2014 10:00:07 +0000 http://www.impressivewebs.com/?p=11415 Cursor-Over-Text Behaviour in BrowsersBy default, in all major browsers, when you hover your mouse over text on a web page, the cursor changes from the regular arrow (the “default” cursor) to a “text” cursor.

      You can see this demonstrated in the GIF below or by simply testing it out on just about any web page:

      ]]>
      By default, in all major browsers, when you hover your mouse over text on a web page, the cursor changes from the regular arrow (the “default” cursor) to a “text” cursor. You can see this demonstrated in the GIF below or by simply testing it out on just about any web page:

      Cursor changes fropm default to text

      To be more precise, the “default” cursor is not technically required by the spec to be the default. The initial value of the cursor property is actually “auto”, meaning that, as the spec says, “the UA determines the cursor to display based on the current context.”

      When defining the “text” value for the cursor property, the spec explains: “Indicates text that may be selected. Often rendered as a vertical I-beam.”

      But, as you probably know, this can be overridden in CSS, so you can display whatever cursor you want, any time you want. Notice, for example, on SitePoint that the CSS is overriding the behaviour on plain text:

      Cursor doesn't change

      I can’t think of another site at the moment that does this no-text-cursor thing on text. I remember when A List Apart was redesigned, they had originally done the same thing that SitePoint is now doing, using the default cursor on text, but that’s been changed back to the default behaviour.

      What’s the Correct Behaviour?

      If you go by the spec, the “text” cursor (the vertical I-beam) is the correct one to use. And if you go by what people are accustomed to, then you’d also have to go with the “text” cursor.

      I think at this stage there would be no point in trying to change the way browsers and developers handle this, especially since all browsers do this by default, thus making it easy to have the same behaviour basically everywhere — even if it is the wrong behaviour.

      But I can’t help but think: Doesn’t this go against the behaviour in native apps?

      Here’s what happens in every browser when you move your cursor to the address bar:

      Cursor is ready to edit

      This happens, not because it’s text in the address bar, but because it’s editable text. What about elsewhere in Chrome, like in the Chrome settings page:

      Cursor stays default on page

      Notice that Chrome’s settings page (which is just a web page, within which you can inspect elements and view source) they’ve overridden the default behaviour to use the “default” cursor when the cursor is hovered over text.

      They probably do this to keep the settings page as “native” as possible, even though it’s still just a web page. The user can therefore see that the text on that page is not editable, but the text in the search box is.

      This is generally the pattern with native apps: Editable text uses the vertical I-beam cursor while regular, non-editable text uses the default arrow.

      Update: As pointed out in the comments, many feel that native apps use the I-beam cursor not just for editable text but also for any selectable text. In most cases, this seems to be the case. Personally, I think the I-beam cursor feels more natural as an “insert text” or “edit this text” indicator, rather than a selection indicator. And I think there are native apps that include selectable text where the cursor is just the default arrow. But it’s not often like that so much of my point here regarding native is somewhat lost when you consider that the I-beam is used almost universally for selectable and editable text.

      Conclusion

      I don’t know the history of why browsers use the “text” cursor on non-editable text. Some websites, like SitePoint, have recognized that maybe it would be better to go with the native experience in this regard.

      On any web page, I think it makes more sense if the text cursor is reserved for editable elements like textarea, input, and even elements with the contenteditable attribute.

      What do you think? Have browser been doing this wrong all along? I don’t think we can do anything to change this, but I suppose if we got to the point where all in-use browsers auto-updated, the vendors could agree to use the more intuitive native behaviour in this regard.

      Oh and sorry for all the animated cursors. I’m sure that wasn’t annoying at all. :)

      ]]>
      http://www.impressivewebs.com/cursor-over-text-behaviour-browsers/feed/ 24
      w3schools: The Ugly, the Bad, and the Good http://www.impressivewebs.com/w3schools-ugly-bad-good/ http://www.impressivewebs.com/w3schools-ugly-bad-good/#comments Wed, 12 Feb 2014 11:00:15 +0000 http://www.impressivewebs.com/?p=10654 w3schools logoFor the record, I don’t hate w3schools. Apparently, a lot of people find their website useful. And from a human perspective, I’m happy for their success. After all, it’s run by one or more people, just like you and me, who have to feed their families.

      But with everything we know about SEO and web development best practices, their ability to remain at the top of search results and also be in the top 200 most-visited websites in the world even after Google has made so many updates to their ranking algorithms, baffles us all.

      In this post I’ll attempt to analyze a number of things about the w3schools.com website, both good and bad (mostly bad) and see if we can’t learn a few things and draw some conclusions.

      ]]>
      w3schools logoFor the record, I don’t hate w3schools. Apparently, a lot of people find their website useful. And from a human perspective, I’m happy for their success. After all, it’s run by one or more people, just like you and me, who have to feed their families.

      But with everything we know about SEO and web development best practices, their ability to remain at the top of search results and also be in the top 200 most-visited websites in the world even after Google has made so many updates to their ranking algorithms, baffles us all.

      In this post I’ll attempt to analyze a number of things about the w3schools.com website, both good and bad (mostly bad) and see if we can’t learn a few things and draw some conclusions.

      And keep in mind that not everything I discuss here has an impact on SEO – or ever will for that matter – but I thought this would be a nice case study for some general do’s and don’ts.

      They Use Classic ASP

      Update (Feb. 13, 2014) Apparently, this is not correct. As comments have pointed out, and as pointed out on Hacker News, you can use the command line or an online tool to find out what technologies the site is built on. Evidently it’s ASP.NET on IIS. I knew it was possible to use whatever file extension they want. But I just didn’t think they would do that. Why would someone use “aspx” pages and spoof the file names to look like classic ASP? SEO-friendly redirects should probably be used and they should just use extension-free URLs instead. But hey, it works for them, so whatevs.

      Seriously? In 2014? Even after a redesign a few years ago, their pages still use “.asp”, which is basically an extinct platform that almost nobody uses anymore. VBScript, the language used in most classic ASP pages, is #98 in the top 100 programming languages by popularity.

      Classic ASP

      I was a classic ASP developer for years, and it’s been about 7 years since I touched ASP, let alone coded it regularly. At the very least, couldn’t they reference directories with the “default.asp” hidden, to cloak this fact? In addition, they still have an entire section devoted to classic ASP tutorials (although this is not currently featured prominently).

      Script Tag Madness

      The code from one of their pages is shown below. It loads at least 15 different script tags, only two of which load at the bottom. Don’t tell Paul.

      Too many Scripts

      Having this many scripts load in the head without combining them or minifying goes against the fairly commonly known advice to reduce HTTP requests and put scripts at the bottom.

      Interestingly, the generated source viewed in dev tools has 25 <script> elements, so they seem to be injecting quite a few of those on the fly.

      They Use Inline Styles

      Their use of inline CSS is nonsensical and doesn’t seem to have method to its madness. It also looks like some of it is injected with JavaScript.

      Inline Styles

      There are tons of elements on w3schools that have inline styles and those same elements often have classes and IDs that apply CSS from external style sheets. I have no idea why they would mix and match their styles like this for such a large website that would be difficult to maintain even with good code.

      Inline styles have generally been viewed as bad practice for years now for a number of reasons.

      They Use Ancient Float-Clearing Methods

      Littered in their code is stuff like this:

      Ancient float clearing methods

      This is done with empty divs and <br> elements. All of which could be corrected with a simple, reusable clearfix.

      They Use Tables for Layout

      This is not as bad as it used to be. From what I recall, before their most recent redesign, they were primarily using full table-based layouts for just about everything.

      Tables for Layout

      As shown above, they still use these in unnecessary places.

      They Have Duplicate Content

      This is something I examined in an older article, so check that out if you want more details – it’s pretty bizarre.

      Classic ASP

      In short, they have duplicate content under different subdomains. Although duplicate content, for SEO, should be kept to a minimum, this doesn’t seem to affect their rankings. In fact, if anything, it seems to help them.

      Their Embedded Code Examples are Ugly

      It’s hard to believe a tutorial website as popular as w3schools would post code that looks like this:

      Embedded code

      Not only is it poorly formatted, but it’s not using syntax highlighting. And that’s just the on-page code examples in their lessons. Their own CSS is just as bad:

      w3schools' own CSS

      Code, especially in embedded examples, should always use good formatting for readability.

      They Use Reflections

      For this, I would penalize them in search rankings on principle alone.

      Reflections

      2008 web design trends FTW!

      They Think “CSS3” is Part of “HTML5”

      We should sic Jeremy on them for this faux pas.

      CSS3 is not HTML5

      And what’s with the jaggedy HTML5 logo in GIF format? Shouldn’t someone who teaches web design know that PNG, JPEG, or SVG would be more appropriate in this instance?

      They Use <br> Tags Badly

      The <br> tag has its place, but if you’re using it to create margin/padding-like space inside elements (like w3schools often does), then you’re using it poorly.

      Poor BR tag use

      And often they’re doing this before <h2> elements and inside divs that have classes and IDs attached to them. Clearly they could do this in the external CSS instead or by using paragraph tags.

      They Use the “keywords” Meta Tag

      Update (April 8, 2014) It turns out, they’re probably using the keywords meta tag for other major search engines, like Baidu, which according to at least one source, considers meta tags as a “major” ranking factor.

      Of course, this won’t harm their ranking, but it accomplishes nothing and yet all their pages use it.

      Meta Keywords

      From what I can see, all pages use the exact same keywords, so it seems to be part of their basic site template and they’ve never removed it. “Just in case”, I guess.

      Their Website is Not Responsive or Mobile-Friendly

      This would probably be a tough one for an older site that’s as big as they are, but this should definitely be on their to-do list if they want to increase revenue.

      Not responsive

      (Using Matt Kersley’s tool)

      Of course, I don’t think this would reduce their search rankings (does anything??), but they would be much more respectable with a proper mobile-friendly site.

      Is There Anything Good?

      So that’s much of the bad that isn’t covered elsewhere, and that sure was fun.

      But is there anything good we can say about w3schools? There absolutely is, and these factors below might be more relevant than we realize.

      Their Pages Don’t Have Major Accessibility Errors

      While they do have 56 “contrast errors”, when testing their pages using WebAIM’s accessibility checker, they score fairly well, with no major errors.

      Good WAVE results

      By way of comparison, as of this writing CSS-Tricks had 3 errors and 70 contrast errors; Smashing Magazine had 4 errors and 0 contrast errors; A List Apart had 2 errors and 12 contrast errors; SitePoint had 7 errors and 42 contrast errors; and MDN’s reference had 1 error and 57 contrast errors.

      Their Page Speed Tests are Strong

      Amazingly, even despite all the extra script tags in the head, every page of w3schools.com that I tested using YSlow registered with an “A” grade, which is amazing. This is true even on the page mentioned above that loads 25 scripts.

      YSlow A Grade

      In addition, they get a strong score for their home page and inner pages on Google’s PageSpeed Insights, for both mobile and desktop:

      Strong PageSpeed Insights Score

      And they score well using other tools too:

      Fast pages

      MDN’s reference also grades with an “A” in YSlow, but the page speed tests tended to be slower:

      MDN's speed test

      Conclusions

      As mentioned, w3schools’ strong rankings can be infuriating. But I wonder if a lot of what I’ve discussed here has something to do with their ability to maintain their rank.

      Naturally, the age of their website and the number of inbound links they have play a major factor in their ranking. But consider the following:

      • Just about all their pages seem to load fast, which we know is relevant to SEO.
      • They use a lot of inline CSS, which, according to recent research, might be a good thing for performance.
      • They don’t overuse various CSS3 and HTML5 effects, which again keeps their pages slim and fast (their home page and inner pages are about 350-550KB, which is reasonably good).
      • They use alt text for images and, generally speaking, seem to have robot-friendly pages.

      Yes, even after a redesign, their website still looks like it fell out of the 1999 tree, hitting every branch on the way down. And it’s been demonstrated that they have many technical inaccuracies in their content.

      But those things that you and I personally find problematic don’t matter to Google’s ranking algorithm. Nor would it make any sense for Google to penalize them for “old school” practices. That would be detrimental to the integrity of the search algorithm because not only would it contradict giving higher rankings to older more established sites, but it would also go against the web’s friendliness towards backwards compatibility.

      After doing this examination, and barring a conspiracy, I’m no longer too surprised that w3schools have good search rankings. And if they’ve helped beginners get their footing in the industry, then that’s a good thing.

      Oh, and if you “view source” on any of my websites, you’ll see that I’m not exactly in a position to nitpickingly criticize others. It’s just too fun not to! :)

      ]]>
      http://www.impressivewebs.com/w3schools-ugly-bad-good/feed/ 76
      Promoting Something? Here’s Some Advice. http://www.impressivewebs.com/promoting-something-advice/ http://www.impressivewebs.com/promoting-something-advice/#comments Fri, 31 Jan 2014 11:00:33 +0000 http://www.impressivewebs.com/?p=10586 My blog is not nearly as popular as some other websites in the industry. But I regularly get emails from people through my contact form, asking about various things, including:]]> My blog is not nearly as popular as some other websites in the industry. But I regularly get emails from people through my contact form, asking about various things, including:

      • Link exchanges
      • Buying text links
      • Advertising on my site
      • Paying me to post a product review
      • …and so on…

      I understand why business owners are trying to do these things, and a few of these are legitimate business practices. It’s not easy getting a startup off the ground, and it’s not easy for a new company, product, or service, to get SEO-driven traffic. I feel your pain, I really do. We all face these issues.

      But 99% of the people who contact me about these things haven’t got a clue about human relations. It’s annoying, because not only does it waste time for both of us, but it also takes away a legitimate opportunity for me to actually consider whatever it is they’re offering.

      So if you are in the business of cold-contacting people online to promote your product or service, here is a very simple piece of advice:

      Tell me what your product is.

      I can’t believe how many vague emails I get that sound like this:

      Hi, we would like to have one of our product review on your blog ImpressiveWebs. Do you allow sponsored reviews? How much does it cost?

      The above is a real email I got about 1 minute before beginning to write this post. I get so many of these, and they sound like they’re all written by the same person.

      For the love of all things good and pure, fill in some pertinent details! Why should both of us waste time exchanging 3 or 4 emails before I even know what it is you want to advertise? Even if I did publish sponsored articles (which I don’t; but it certainly is tempting in this age of ad blockers), there are some things that I would never publish. I have to know what your product is, otherwise you’re just wasting my time. In most cases, I won’t even respond to these emails, I’ll just insta-delete (which, interestingly, saves me tons of time).

      This applies to anything you are emailing me about: Sponsored articles, link exchanges, text link buying, etc. It’s not that difficult, really. Just tell me about the product, and send me a link or two.

      I know that many of these requests do not come from the companies providing the services, but instead a marketing company makes these requests in their behalf. But truthfully, this is even more surprising, since it’s the marketing company’s job to open these doors of opportunity. With these vague emails, they’re harming their clients’ chances of getting any exposure.

      Of course, nobody should resort to this type of thing. Most of these requests are for spammy products and services that I would never want associated with my website. But even so, if these emails were specific, considerate, and written in a more down-to-earth manner, I would be much more likely to give them a minute or more of my time.

      From this point on, whenever I get an email like the one above, I will be directing them to this post.

      ]]>
      http://www.impressivewebs.com/promoting-something-advice/feed/ 14