John's Random Thoughts and Discussions
Building Larder Shelving
Creating a place to store your canned goods is an essential part of making self-sufficiency work. In Fun is Where You Find It! (Part 3) you see one view of the larder shelving we use to store our canned goods in the basement. The shelving has to be built to withstand the weight of the canned goods without sagging. In addition, you want to be able to support part of someone's weight when they need to regain their footing.
In order to create our shelving, I played with some wood and actually weighted it down to see when it would sag. I then used those assumptions to start designing the shelving and to feed the numbers into the Sagulator. The maximum amount of sag you should be willing to tolerate is 0.01 inch per foot. You need an engineering margin to ensure the shelves will hold up.
Of course, the problem is getting the numbers the Sagulator requires. A typical quart jar of canned goods filled with a liquid weighs 3 pounds. If you make the shelves 24 inches deep using three 1 × 8 boards and create spans of 25 inches, you can store 42 jars per span for a total weight of 126 pounds. Using #2 Douglas fir, you get a sag of 0.01 inch. You must consider the kind of wood that you're using as part of your calculation and keep refining the measurements until you obtain a setup that works.
You also need to consider the shelf spacing. It's important to allow finger spacing between the shelves so that someone can reach all the way into the back to retrieve a jar without problem. After a lot of experimentation, I came up with the following shelf spacing:
To create our new larder shelving, I started with four 2 × 4 supports tied into the ceiling joists. You absolutely don't want the shelves falling on you, so make sure you use sturdy screws. I relied on 5-inch heavy decking screws that went completely through both the 2 × 4 support and the joist as shown here.
Make sure you use at least two sturdy screws to hold each framing member for the shelves for each shelf you create. My shelving ended up being 75 inches long, 24 inches deep, and 84 inches high. The shelving arrangement includes one shelf for five gallon buckets, two shelves for quart jars, and three shelves for pint jars as shown here.
Make absolutely certain you keep everything square and level as you build because any deviation will lower the amount of weight the shelving can carry. Each shelf should be tied into every framing member with at least two screws. In this case, that means eight screws per board or 24 screws for each shelf (because there are three 1 × 8 boards used for each shelf).
Because of the shelf heights, you'll find that you have to insert the screws at an angle. Actually, this is a good way to add the shelving anyway because the screws gain greater purchase in the wood. However, make sure you alternate the direction you screw the screws so that you don't end up racking the shelving (making it out of square or level). Here is how your screw pattern should look.
In this case, the first and third shelves have screws coming in from the right, while the second (center) shelf has them coming in from the left. In the next section, I reversed the direction so that the first and second shelves came in from the left, while the second shelf came in from the right. Alternating directions like this helps make the shelves stronger.
Every shelf should also have a backer board to keep the canned goods from simply falling out the back of the shelf. In this case, I used 1 × 6 boards secured with two screws in each section. The backer boards also provide added strength to the entire unit.
Finally, to keep things from sliding out of either side and to also provide places to put hooks for items we wish to hang, I added end pieces. These end pieces are made from two 1 × 10 and one 1 × 8 boards. Here is how the shelving looked after I finished it (with some items already in place).
When building shelving, make sure you take time to ensure that the shelving will actually hold the items you want to put on it. The essential issue is to control sag so that the shelving doesn't fail in the long term. Let me know your thoughts about larder shelving at John@JohnMuellerBooks.com.
In order to create our shelving, I played with some wood and actually weighted it down to see when it would sag. I then used those assumptions to start designing the shelving and to feed the numbers into the Sagulator. The maximum amount of sag you should be willing to tolerate is 0.01 inch per foot. You need an engineering margin to ensure the shelves will hold up.
Of course, the problem is getting the numbers the Sagulator requires. A typical quart jar of canned goods filled with a liquid weighs 3 pounds. If you make the shelves 24 inches deep using three 1 × 8 boards and create spans of 25 inches, you can store 42 jars per span for a total weight of 126 pounds. Using #2 Douglas fir, you get a sag of 0.01 inch. You must consider the kind of wood that you're using as part of your calculation and keep refining the measurements until you obtain a setup that works.
You also need to consider the shelf spacing. It's important to allow finger spacing between the shelves so that someone can reach all the way into the back to retrieve a jar without problem. After a lot of experimentation, I came up with the following shelf spacing:
- 8 inches for quart jars stacked one high
- 10 inches for pint jars stacked two high
- 16 ¾ inches for 5 gallon buckets and canning equipment
To create our new larder shelving, I started with four 2 × 4 supports tied into the ceiling joists. You absolutely don't want the shelves falling on you, so make sure you use sturdy screws. I relied on 5-inch heavy decking screws that went completely through both the 2 × 4 support and the joist as shown here.
Make sure you use at least two sturdy screws to hold each framing member for the shelves for each shelf you create. My shelving ended up being 75 inches long, 24 inches deep, and 84 inches high. The shelving arrangement includes one shelf for five gallon buckets, two shelves for quart jars, and three shelves for pint jars as shown here.
Make absolutely certain you keep everything square and level as you build because any deviation will lower the amount of weight the shelving can carry. Each shelf should be tied into every framing member with at least two screws. In this case, that means eight screws per board or 24 screws for each shelf (because there are three 1 × 8 boards used for each shelf).
Because of the shelf heights, you'll find that you have to insert the screws at an angle. Actually, this is a good way to add the shelving anyway because the screws gain greater purchase in the wood. However, make sure you alternate the direction you screw the screws so that you don't end up racking the shelving (making it out of square or level). Here is how your screw pattern should look.
In this case, the first and third shelves have screws coming in from the right, while the second (center) shelf has them coming in from the left. In the next section, I reversed the direction so that the first and second shelves came in from the left, while the second shelf came in from the right. Alternating directions like this helps make the shelves stronger.
Every shelf should also have a backer board to keep the canned goods from simply falling out the back of the shelf. In this case, I used 1 × 6 boards secured with two screws in each section. The backer boards also provide added strength to the entire unit.
Finally, to keep things from sliding out of either side and to also provide places to put hooks for items we wish to hang, I added end pieces. These end pieces are made from two 1 × 10 and one 1 × 8 boards. Here is how the shelving looked after I finished it (with some items already in place).
When building shelving, make sure you take time to ensure that the shelving will actually hold the items you want to put on it. The essential issue is to control sag so that the shelving doesn't fail in the long term. Let me know your thoughts about larder shelving at John@JohnMuellerBooks.com.
There is No Start Menu
A number of readers have recently asked me about the viability of my comments about the Start menu in Windows 8 for Dummies Quick Reference. There are a number of stories that make it seem as if Microsoft is adding the Start menu back into Windows 8.1. You'll see article titles such as, "Windows 8.1 set to bring back the Start button" online. It's only when you start reading the details in the article that you realize that the title is misleading at best—someone with Microsoft marketing might well have written it. The fact is, if you want Start menu functionality in Windows 8 or 8.1, you still need a third party product such as ViStart. I discuss the updated features of this product in my ViStart Updates post.
In order to get a better idea of just how Windows 8.1 changes things, you need to read articles such as "Leaked Windows 8.1 Build 9374 disappoints Start button fans." I'll also be providing updates as readers ask specific questions and more information about Windows 8.1 becomes available. Remember that Windows 8.1 won't be released until late this year (assuming Microsoft remains on schedule).
So far, my take on Windows 8.1 is that it doesn't change much—it mainly fixes problems or addresses fit and finish issues. For example, a lot of people rightfully complained about being able to display only one or two apps on screen. (After all, this is a step backward compared to Windows 7.) Even with Windows 8.1, the ability to view more apps on a single screen will only work when your device has sufficient resolution (a minimum of 1366 pixels in Windows 8). The new version is supposed to let you view up to four apps at a time, but it sounds as if you need a high resolution display to do it. It does appear that you'll at least be able to split the screen as long as you have a 1024 × 768 display, but this really isn't much of a help.
There are some window dressing changes as well, which I won't address until I see an updated beta. In addition, Windows 8.1 could work on other platforms. The point is, the Windows 8 book you have in your hands now should work just fine with Windows 8.1 as well. I'll provide updates on the blog after Microsoft releases Windows 8.1. In the meantime, don't believe all the rumors you see online. Windows 8.1 is an incremental release, much as the version number states. Let me know if you have any other questions or concerns about the book content at John@JohnMuellerBooks.com.
In order to get a better idea of just how Windows 8.1 changes things, you need to read articles such as "Leaked Windows 8.1 Build 9374 disappoints Start button fans." I'll also be providing updates as readers ask specific questions and more information about Windows 8.1 becomes available. Remember that Windows 8.1 won't be released until late this year (assuming Microsoft remains on schedule).
So far, my take on Windows 8.1 is that it doesn't change much—it mainly fixes problems or addresses fit and finish issues. For example, a lot of people rightfully complained about being able to display only one or two apps on screen. (After all, this is a step backward compared to Windows 7.) Even with Windows 8.1, the ability to view more apps on a single screen will only work when your device has sufficient resolution (a minimum of 1366 pixels in Windows 8). The new version is supposed to let you view up to four apps at a time, but it sounds as if you need a high resolution display to do it. It does appear that you'll at least be able to split the screen as long as you have a 1024 × 768 display, but this really isn't much of a help.
There are some window dressing changes as well, which I won't address until I see an updated beta. In addition, Windows 8.1 could work on other platforms. The point is, the Windows 8 book you have in your hands now should work just fine with Windows 8.1 as well. I'll provide updates on the blog after Microsoft releases Windows 8.1. In the meantime, don't believe all the rumors you see online. Windows 8.1 is an incremental release, much as the version number states. Let me know if you have any other questions or concerns about the book content at John@JohnMuellerBooks.com.
Making Smart Computer Language Choices
Many readers have asked over the years why I spent time learning the computer languages that I have. Some languages were learned as part of the requirement for getting my computer science degree and a few were learned as part of getting a job. However, most languages were learned as a means to communicate better with the computer. A computer speaks only one language—machine code, which is nearly impossible for humans to learn. My first coding experiences started with machine code and then progressed to languages such as Macro Assembler (MASM). As technology has improved and my needs have changed, I've learned other languages, which is why I wrote "6 Ways to Determine a New Programming Language is a Turkey."
Some of the languages I've learned over the years really were turkeys. The language is probably acceptable, but I didn't get anything for my efforts. The language wasn't right for me—it didn't help me to communicate better with the computer. You'll likely find that you experience the same problem if you spend enough time writing code. The more time you spend writing applications, the more languages you eventually learn.
I rarely get into arguments with other people who feel the language they like best is superior to all others. I realized a long time ago that the language really is superior from their perspective. If I were in their precise situation and writing exactly the same kinds of application they're writing, I'd probably come to the same conclusion. That's why the choice of language is both personal and imprecise. My article helps you make an informed choice based on the criteria that I use most often to select a new language. An informed choice will reduce the mistakes you make when selecting a language.
The point at which some developers make a mistake is in thinking that the computer pays any attention at all to the language they choose. The computer couldn't care less. All the computer knows is machine code. The language you choose is for your benefit, not the computer's benefit. The moment you start thinking that a language does anything at all for the computer, the chances of choosing a turkey increase greatly.
There are some mechanics of computer languages that you do need to consider. For example, you need to know that the language you choose will translate into machine code your computer understands. You also need to know that the more comfortable you make things for yourself, the less efficient the code becomes. That's not really a problem in today's environment of high-powered computers, but that reality did affect my decisions early in my career. At the time, MASM provided the most efficient means possible to communicate with a computer without resorting to machine code. Even so, MASM was difficult to work with and I welcomed the introduction of C as a means of making things easier on myself.
Of course, this all leads into the question of which language you feel works best for your needs today. Some developers know just one language well—others, like myself, have an entire toolbox full of languages to use to meet specific needs. Where do you fall into the list? As I continue to write books, I'd like to hear about languages and techniques for using those languages that interest you most. Let me know your thoughts on computer languages at John@JohnMuellerBooks.com.
Some of the languages I've learned over the years really were turkeys. The language is probably acceptable, but I didn't get anything for my efforts. The language wasn't right for me—it didn't help me to communicate better with the computer. You'll likely find that you experience the same problem if you spend enough time writing code. The more time you spend writing applications, the more languages you eventually learn.
I rarely get into arguments with other people who feel the language they like best is superior to all others. I realized a long time ago that the language really is superior from their perspective. If I were in their precise situation and writing exactly the same kinds of application they're writing, I'd probably come to the same conclusion. That's why the choice of language is both personal and imprecise. My article helps you make an informed choice based on the criteria that I use most often to select a new language. An informed choice will reduce the mistakes you make when selecting a language.
The point at which some developers make a mistake is in thinking that the computer pays any attention at all to the language they choose. The computer couldn't care less. All the computer knows is machine code. The language you choose is for your benefit, not the computer's benefit. The moment you start thinking that a language does anything at all for the computer, the chances of choosing a turkey increase greatly.
There are some mechanics of computer languages that you do need to consider. For example, you need to know that the language you choose will translate into machine code your computer understands. You also need to know that the more comfortable you make things for yourself, the less efficient the code becomes. That's not really a problem in today's environment of high-powered computers, but that reality did affect my decisions early in my career. At the time, MASM provided the most efficient means possible to communicate with a computer without resorting to machine code. Even so, MASM was difficult to work with and I welcomed the introduction of C as a means of making things easier on myself.
Of course, this all leads into the question of which language you feel works best for your needs today. Some developers know just one language well—others, like myself, have an entire toolbox full of languages to use to meet specific needs. Where do you fall into the list? As I continue to write books, I'd like to hear about languages and techniques for using those languages that interest you most. Let me know your thoughts on computer languages at John@JohnMuellerBooks.com.
More Goodies for HTML Programming with Javascript For Dummies
During the last few weeks I've mentioned some of the extras you can get for HTML5 Programming with JavaScript For Dummies. There are even more goodies and you can access them through the Extras page. All new Dummies books will likely include this special page where you can obtain access to the Cheat Sheet and a number of other items that will vary by book. Of course, I've already told you about the article on using tooltips to make your pages more accessible.
While I wrote this book, I tried to avoid too many specific references to particular products. My goal was to provide a book that anyone could use on the Mac, Linux, or Windows platforms without modification. The examples were designed to work with just about any major browser; although, I did focus on Chrome, Firefox, and Internet Explorer during testing. Even though I did follow these guideline rigorously while writing, I also used some specific tools to write my code. You can read about one of these tools in the article entitled, How to Create a New JavaScript File in Komodo Edit. Make sure you let me know whether you'd like to see more articles on this exciting editor. I'll post them along with the other blog posts for this book.
If you have already performed some programming with JavaScript, you know that the prototype can be particularly difficult to understand. In fact, while researching this book, I noted an inordinate number of questions about this particular JavaScript element. The book does address the prototype property to some degree, but you may want a little more information. I provide it as part of the article entitled, How to Use the JavaScript Prototype Property.
Some developers make working with CSS mysterious and difficult. Fortunately, there is a way to make things simple. No, you won't use every feature that CSS has to offer using my technique, but you'll get an excellent start on organizing information on your site. The article entitled, How to Create Cascading Style Sheets (CSS) Simply and Easily, describes this technique in detail.
A final article for the Extras page considers the idea that many people learn by viewing what other people have done. Mimicking the actions of others is an excellent way to learn. That's why I created Ten Really Cool Sites You Can Emulate. This is a simple list of ten sites you can use to learn by seeing what other people have done for their sites. I chose each site in the list for a specific reason and the article tells you why.
The Extras page is a good way to discover whether you'll like my book and whether my style of writing suits your needs. I encourage you to check out the Extras page, along with the extensive list of blog posts you find here. Of course, I'm always happy to answer your questions. If you find that you need additional information before buying my book or after you start reading it, please be sure to contact me at John@JohnMuellerBooks.com.
While I wrote this book, I tried to avoid too many specific references to particular products. My goal was to provide a book that anyone could use on the Mac, Linux, or Windows platforms without modification. The examples were designed to work with just about any major browser; although, I did focus on Chrome, Firefox, and Internet Explorer during testing. Even though I did follow these guideline rigorously while writing, I also used some specific tools to write my code. You can read about one of these tools in the article entitled, How to Create a New JavaScript File in Komodo Edit. Make sure you let me know whether you'd like to see more articles on this exciting editor. I'll post them along with the other blog posts for this book.
If you have already performed some programming with JavaScript, you know that the prototype can be particularly difficult to understand. In fact, while researching this book, I noted an inordinate number of questions about this particular JavaScript element. The book does address the prototype property to some degree, but you may want a little more information. I provide it as part of the article entitled, How to Use the JavaScript Prototype Property.
Some developers make working with CSS mysterious and difficult. Fortunately, there is a way to make things simple. No, you won't use every feature that CSS has to offer using my technique, but you'll get an excellent start on organizing information on your site. The article entitled, How to Create Cascading Style Sheets (CSS) Simply and Easily, describes this technique in detail.
A final article for the Extras page considers the idea that many people learn by viewing what other people have done. Mimicking the actions of others is an excellent way to learn. That's why I created Ten Really Cool Sites You Can Emulate. This is a simple list of ten sites you can use to learn by seeing what other people have done for their sites. I chose each site in the list for a specific reason and the article tells you why.
The Extras page is a good way to discover whether you'll like my book and whether my style of writing suits your needs. I encourage you to check out the Extras page, along with the extensive list of blog posts you find here. Of course, I'm always happy to answer your questions. If you find that you need additional information before buying my book or after you start reading it, please be sure to contact me at John@JohnMuellerBooks.com.
Rabbits Do Talk!
Some people envision rabbits as these quintessentially quiet animals who sit silently and never make their feelings known. However, in the real world, rabbits are actually quite vocal and will let you know precisely how they feel about any given topic. Of course, as with people, some rabbits are more vocal than others are. A few rabbits actually are quite docile and you must coax their feelings from them, but they're rare (as are quiet people).
If you listen, your rabbit will talk to you. For example, if you hear a growling type noise, it means that your rabbit is annoyed or feels threatened in some way. When threatened, the rabbit will back into a corner (or at least away from the threat). However, when the rabbit is annoyed, it follows the growl with a loud thump from those tremendous feet. (OK, they don't look all that huge to you, but when you consider the rabbit's overall size, those feet really are monsters.)
Females who are annoyed with the male in their cage really do growl quite loud and will sometimes charge the male. In fact, several females we've had were quite willing to take a chunk out of the poor guy's back (and all he was doing was asking for a date). If the female is feeling territorial, the growl may become a shorter and louder bark. When you see this behavior, it means the female is bred and the male had better just leave as quickly and as quietly as possible. If you hear barking from two males, it means that they're both alpha males and are about ready to get into a fight. You must move one of the two males to a different cage.
A change in cage can sometimes trigger an annoyance response. We moved one of our rabbits to a different (and we thought nicer) cage. The rabbit was obviously not impressed. She spent quite some time charging at us, thumping her feet, and growling quite loudly. In some cases, she preceded a lunge with a hiss, which showed a kind of extreme annoyance. Yes, we heard her loud and clear (unfortunately, there was little we could do to appease her and she finally decided the new cage would be just fine after all).
Sometimes thumping goes hand-in-hand with some sort of physical demonstration. One male seemed quite annoyed that another rabbit (a female and her kits) had received all the nice carrot shavings while he was offered the same dry rabbit pellets as normal. So he thumped quite loudly and then threw his dish across the cage. We decided that the extra carrot in the refrigerator would make a wonderful peace offering and the rabbit agreed. The chickens ate the food that fell through the bottom of his cage, so everyone seemed quite happy with the way things turned out.
Honking is another vocalization. Think of it as someone with a serious sinus condition and you get the idea. A rabbit will generally make this noise when happy or wanting attention. Some of our breeder rabbits will actually shovel their noses into us and then honk to demonstrate that we really do need to pay attention to them. Of course, if we show them some, but not enough attention, the rabbit will almost certainly thump when we close the cage (and possibly throw the food dish against the wall as well).
Some rabbits will also grind their teeth when they are happy and want attention. Teeth grinding is a good thing and you want to hear it. It's important to note that the teeth grinding in this case is quiet and light, not the heavy grinding associated with eating something.
Along with honking and teeth grinding, seriously happy rabbits will sometimes coo. Depending on the kind of rabbit and the level of happiness, some people associate this sound with a sort of buzzing noise. The rabbit will usually be extremely relaxed, sometimes with its back legs splayed out, and normally with its eyes closed.
Finally, there is the sound no one wants to hear, the high pitched rabbit scream. You normally hear it when the rabbit is in pain or in fear of its life. If you hear this sound, you know the rabbit needs immediate help. We heard it when some feral dogs in the area decided they might like a rabbit for dinner. Fortunately, our cages are well-built and the dogs didn't have their way, but the rabbits in those cages were screaming quite loud. In fact, at least one of them passed out from fright (it later recovered).
Facial activities can also alert you to a rabbit's mood. For example, twitching whiskers often denote curiosity (normally for a food item, but also for attention). The faster those whiskers twitch, the more curious the rabbit. Ears held forward and at the alert tell you that the rabbit has heard an unexpected sound. We've noted that some rabbits will furrow their brow when upset or annoyed.
What sorts of sounds does your rabbit make? Have you noticed facial expressions, positions of back feet and ears, and other behaviors that help you understand what your rabbit is trying to say? Let me know what you've observed at John@JohnMuellerBooks.com.
If you listen, your rabbit will talk to you. For example, if you hear a growling type noise, it means that your rabbit is annoyed or feels threatened in some way. When threatened, the rabbit will back into a corner (or at least away from the threat). However, when the rabbit is annoyed, it follows the growl with a loud thump from those tremendous feet. (OK, they don't look all that huge to you, but when you consider the rabbit's overall size, those feet really are monsters.)
Females who are annoyed with the male in their cage really do growl quite loud and will sometimes charge the male. In fact, several females we've had were quite willing to take a chunk out of the poor guy's back (and all he was doing was asking for a date). If the female is feeling territorial, the growl may become a shorter and louder bark. When you see this behavior, it means the female is bred and the male had better just leave as quickly and as quietly as possible. If you hear barking from two males, it means that they're both alpha males and are about ready to get into a fight. You must move one of the two males to a different cage.
A change in cage can sometimes trigger an annoyance response. We moved one of our rabbits to a different (and we thought nicer) cage. The rabbit was obviously not impressed. She spent quite some time charging at us, thumping her feet, and growling quite loudly. In some cases, she preceded a lunge with a hiss, which showed a kind of extreme annoyance. Yes, we heard her loud and clear (unfortunately, there was little we could do to appease her and she finally decided the new cage would be just fine after all).
Sometimes thumping goes hand-in-hand with some sort of physical demonstration. One male seemed quite annoyed that another rabbit (a female and her kits) had received all the nice carrot shavings while he was offered the same dry rabbit pellets as normal. So he thumped quite loudly and then threw his dish across the cage. We decided that the extra carrot in the refrigerator would make a wonderful peace offering and the rabbit agreed. The chickens ate the food that fell through the bottom of his cage, so everyone seemed quite happy with the way things turned out.
Honking is another vocalization. Think of it as someone with a serious sinus condition and you get the idea. A rabbit will generally make this noise when happy or wanting attention. Some of our breeder rabbits will actually shovel their noses into us and then honk to demonstrate that we really do need to pay attention to them. Of course, if we show them some, but not enough attention, the rabbit will almost certainly thump when we close the cage (and possibly throw the food dish against the wall as well).
Some rabbits will also grind their teeth when they are happy and want attention. Teeth grinding is a good thing and you want to hear it. It's important to note that the teeth grinding in this case is quiet and light, not the heavy grinding associated with eating something.
Along with honking and teeth grinding, seriously happy rabbits will sometimes coo. Depending on the kind of rabbit and the level of happiness, some people associate this sound with a sort of buzzing noise. The rabbit will usually be extremely relaxed, sometimes with its back legs splayed out, and normally with its eyes closed.
Finally, there is the sound no one wants to hear, the high pitched rabbit scream. You normally hear it when the rabbit is in pain or in fear of its life. If you hear this sound, you know the rabbit needs immediate help. We heard it when some feral dogs in the area decided they might like a rabbit for dinner. Fortunately, our cages are well-built and the dogs didn't have their way, but the rabbits in those cages were screaming quite loud. In fact, at least one of them passed out from fright (it later recovered).
Facial activities can also alert you to a rabbit's mood. For example, twitching whiskers often denote curiosity (normally for a food item, but also for attention). The faster those whiskers twitch, the more curious the rabbit. Ears held forward and at the alert tell you that the rabbit has heard an unexpected sound. We've noted that some rabbits will furrow their brow when upset or annoyed.
What sorts of sounds does your rabbit make? Have you noticed facial expressions, positions of back feet and ears, and other behaviors that help you understand what your rabbit is trying to say? Let me know what you've observed at John@JohnMuellerBooks.com.
jQuery 2.0 and My Books
A number of readers who know that I work extensively with jQuery have written to tell me about changes to the support it provides for older versions of browsers. In fact, you can read about these changes in a recent InfoWorld article, "jQuery 2.0 drops support for old versions of Internet Explorer." The article title is misleading because there are also apparently changes for other browsers such as Firefox and Chrome as well. My advise is to test your application to ensure it actually works as anticipated with the browsers you want to support before you upgrade to jQuery 2.0 in a production environment.
Of course, the concern from readers is that the code in my books will suddenly stop running in their browsers. There is no need for concern. Even though the examples in my latest book have an URL that points to http://code.jquery.com/jquery-latest.js, if you follow the link you'll find that it actually uses the 1.9.1 version of the library, not the 2.0 version. If you want to be absolutely certain you won't encounter any problems, you can always change this URL to http://code.jquery.com/jquery-1.9.1.js, which ensures you'll continue using the 1.9.1 version no matter how the library changes its site.
As to whether I plan to use the new version of the library in upcoming books, it depends on what I see as trends in the market and requests that I receive from readers. As things are now, I probably won't visit the 2.0 version in my books unless readers specifically request it. Even then, the majority of examples in my books will continue to use the 1.9.1 version until such time as the older browsers it supports lack sufficient market presence to make it a worthwhile tradeoff to continue using the older library. In other words, I'll continue to support the version of the library that works for most people.
Your input is important to me. If you have a particular preference that differs from what I have stated in this post, please let me know at John@JohnMuellerBooks.com. My goal is to provide books that meet the needs of as many people as is possible. At some point, if enough readers find that the older examples in my books simply don't work, I'll do what I usually do and provide updated examples in my blog. Please be sure to let me know your thoughts about third party JavaScript libraries in general and jQuery in specific.
Of course, the concern from readers is that the code in my books will suddenly stop running in their browsers. There is no need for concern. Even though the examples in my latest book have an URL that points to http://code.jquery.com/jquery-latest.js, if you follow the link you'll find that it actually uses the 1.9.1 version of the library, not the 2.0 version. If you want to be absolutely certain you won't encounter any problems, you can always change this URL to http://code.jquery.com/jquery-1.9.1.js, which ensures you'll continue using the 1.9.1 version no matter how the library changes its site.
As to whether I plan to use the new version of the library in upcoming books, it depends on what I see as trends in the market and requests that I receive from readers. As things are now, I probably won't visit the 2.0 version in my books unless readers specifically request it. Even then, the majority of examples in my books will continue to use the 1.9.1 version until such time as the older browsers it supports lack sufficient market presence to make it a worthwhile tradeoff to continue using the older library. In other words, I'll continue to support the version of the library that works for most people.
Your input is important to me. If you have a particular preference that differs from what I have stated in this post, please let me know at John@JohnMuellerBooks.com. My goal is to provide books that meet the needs of as many people as is possible. At some point, if enough readers find that the older examples in my books simply don't work, I'll do what I usually do and provide updated examples in my blog. Please be sure to let me know your thoughts about third party JavaScript libraries in general and jQuery in specific.
The Effects of Using Terminology Incorrectly
I read an interesting article the other day by Lorinda Brandon entitled, "When Buzzwords and Jargon Backfire." The actual article is about the relevance of terms when applied to APIs. However, in a larger sense, the author of the article is spot on in decrying a situation that has continued to occur as long as I've been writing (quite a while). People who are involved in an industry, but don't necessarily understand it completely, misapply terminology related to that industry in a way that causes the terms to lose meaning and focus. In this particular case, the author begs people using certain terminology to explain precisely what they mean and how the resulting infrastructure will benefit the people using it. This is a valid request and one I hope the article's readers will respect.
However, the article brings to mind far more serious misuses of terminology. Many people still don't understand the difference between a hacker (someone who understands and uses technology at a low level to perform useful and usually positive tasks) and a cracker (someone who uses technology, not necessarily at a low level, to break into systems and cause other forms of mischief). As an author who really does care about the misuse of terminology, I often try to explain the difference, but as someone astutely pointed out, I'm probably bailing a sinking boat that has a rather large hole in the bottom. In some cases, the terminology is used incorrectly for so long that it acquires a new meaning. Of course, languages change as does every other living thing, so growth in the form of existing words with new meanings and the addition of entirely new words is both expected and encouraged. Someday I may actually give up trying to distinguish between hacker and cracker (but it won't be today).
However, misusing technical terms doesn't simply affect the growth of our language. Unfortunately, misusing terms can lead to all sorts of negative consequences—some dire. Imagine that someone has made claims for a particular technology and misused terminology to do so. You may obtain the technology with certain expectations based on the precise definition of the terminology, but only later find that the technology doesn't address the need at all. What if that technology is used in the health care industry or as part of heavy construction? The misuse of terminology through ignorance or (worse yet) to sell product isn't acceptable. In most cases, materials written by less skilled authors should be vetted by those who have a firm grasp of the required terminology before the material is released to the public to avoid misinterpretation. It's a simple, yet effective, means of retaining the meaning of special words.
When writing documents of any sort, keeping a dictionary close at hand and consulting with others who understand terminology at a precise level is always a good idea. It may surprise you to know that I still use these two techniques to ensure my writing is as accurate as possible. I don't always succeed and you can be certain that some readers will take me to task for my mistakes. Unlike many authors, I do try to clear up these misunderstandings through my blog posts (which I hope that you read). What terminology do you find most confusing? Which terms do you wish others would use with greater precision? Let me know at John@JohnMuellerBooks.com.
However, the article brings to mind far more serious misuses of terminology. Many people still don't understand the difference between a hacker (someone who understands and uses technology at a low level to perform useful and usually positive tasks) and a cracker (someone who uses technology, not necessarily at a low level, to break into systems and cause other forms of mischief). As an author who really does care about the misuse of terminology, I often try to explain the difference, but as someone astutely pointed out, I'm probably bailing a sinking boat that has a rather large hole in the bottom. In some cases, the terminology is used incorrectly for so long that it acquires a new meaning. Of course, languages change as does every other living thing, so growth in the form of existing words with new meanings and the addition of entirely new words is both expected and encouraged. Someday I may actually give up trying to distinguish between hacker and cracker (but it won't be today).
However, misusing technical terms doesn't simply affect the growth of our language. Unfortunately, misusing terms can lead to all sorts of negative consequences—some dire. Imagine that someone has made claims for a particular technology and misused terminology to do so. You may obtain the technology with certain expectations based on the precise definition of the terminology, but only later find that the technology doesn't address the need at all. What if that technology is used in the health care industry or as part of heavy construction? The misuse of terminology through ignorance or (worse yet) to sell product isn't acceptable. In most cases, materials written by less skilled authors should be vetted by those who have a firm grasp of the required terminology before the material is released to the public to avoid misinterpretation. It's a simple, yet effective, means of retaining the meaning of special words.
When writing documents of any sort, keeping a dictionary close at hand and consulting with others who understand terminology at a precise level is always a good idea. It may surprise you to know that I still use these two techniques to ensure my writing is as accurate as possible. I don't always succeed and you can be certain that some readers will take me to task for my mistakes. Unlike many authors, I do try to clear up these misunderstandings through my blog posts (which I hope that you read). What terminology do you find most confusing? Which terms do you wish others would use with greater precision? Let me know at John@JohnMuellerBooks.com.
Using Tooltips on a Web Page
Some developers focus on functionality, rather the usability, when designing their Web pages. The tradeoff is usually a bad one because users favor usability—they want things simple. One of the issues that I find most annoying on some sites is the lack of tooltips—little balloons that pop up and give you more information about a particular item. Adding tooltips requires little extra time, yet provides several important benefits to the end user:
If you already have my book and find that you want additional information on making your site more accessible so that everyone can use it, check out another one of my books, Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements. This book contains all of the information you'll ever need to address every accessibility issue for any kind of application you want to create.
Accessibility is becoming more and more of a concern as the world's population ages. In fact, everyone will eventually need some type of accessibility assistance if they live long enough. If you're a developer, adding something as simple as tooltips to your pages can make them significantly easier to use. Users should request the addition of accessibility aids when sites lack them (and vote with their pocketbook when site owners refuse to add them). Let me know your thoughts about accessibility in general and tooltips in specific at John@JohnMuellerBooks.com.
- Less experienced users obtain useful information for performing tasks such as filling out a form.
- More experienced users obtain additional information about a given topic or the endpoint of a link.
- Special needs users gain additional information required to make their screen readers functional.
- Developers are reminded precisely why an object is included on the page in the first place.
If you already have my book and find that you want additional information on making your site more accessible so that everyone can use it, check out another one of my books, Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements. This book contains all of the information you'll ever need to address every accessibility issue for any kind of application you want to create.
Accessibility is becoming more and more of a concern as the world's population ages. In fact, everyone will eventually need some type of accessibility assistance if they live long enough. If you're a developer, adding something as simple as tooltips to your pages can make them significantly easier to use. Users should request the addition of accessibility aids when sites lack them (and vote with their pocketbook when site owners refuse to add them). Let me know your thoughts about accessibility in general and tooltips in specific at John@JohnMuellerBooks.com.
Chickens in the Woods
We let our chickens run about as they want. Yes, they have a run so that they can stay in a safe environment when desired or they'll have a protected place to run if something chases them, but chickens do need the freedom to wander about. Besides, letting the chickens run around doing what chickens do best, eating insects, helps reduce the tick population in the woods. So, it didn't surprise me the other day to see chickens in our woods while I was working on a relatively large log. However, I thought that they'd maintain their distance because my chainsaw does make a frightful amount of noise.
As I worked along, I noted that the chickens were getting closer. As soon as they saw me looking at them, they curtsied. Now it may sound quite odd to hear that chickens curtsey, but ours do quite regularly. The move their wings out in a manner reminiscent of a woman holding out her skirts and then they do a bit of a bow legged dip. It really is quite humorous to see. Our chickens curtsey when they want us to pick them up and hold them. Normally, this is followed by some amount of petting and us telling them how good they are. Our birds truly are spoiled in grand fashion.
Since I didn't want to stop cutting the log up, I ignored the chickens and kept working. I felt that they would probably head back the other direction due to the noise of the chainsaw. So, it surprised me quite a lot to look up and see that they had gotten closer still. When they saw me looking again, they curtsied yet again—looking quite annoyed in a chicken sort of a way. I could almost see them huff and they were quite annoyed that their human just hadn't gotten the idea that they really needed to be picked up and told what good birds they were.
Not taking the hint, I decided to continue working on the log. Certainly, they'd get the idea this time and go in the other direction or possibly stop to watch me for a while (something that chickens do relatively often because they really are quite nosy). When I looked up the third time, the chickens had gotten dangerously close to my logging operation and I decided that I really must get them to safety. Seeing me look again, they not only curtsied, but squawked quite loudly in order to better attract my attention.
So, I shut my saw off and went over to the two birds. I picked a bird up in each arm (good thing there weren't three of them). Now, I'm walking down this rather steep hill, one chicken under each arm, hoping that I don't fall. All the while I'm telling the chickens what good birds they are. Eventually, I get to the coop and let them inside. I go inside with them and tell them what good birds they are again and give them some pets. At this point, I closed the run door, got the rest of the birds inside, and then went back to work.
Lesson learned? If your chickens really think they need to be petted and they take the time to curtsey, don't ignore them. I have to admit, they really did make my afternoon better. I laughed about their antics all the way back up the hill where I finished my log, loaded it into the cart, and dumped it down the chute. Feel free to share your favorite humorous chicken story with me at John@JohnMuellerBooks.com.
As I worked along, I noted that the chickens were getting closer. As soon as they saw me looking at them, they curtsied. Now it may sound quite odd to hear that chickens curtsey, but ours do quite regularly. The move their wings out in a manner reminiscent of a woman holding out her skirts and then they do a bit of a bow legged dip. It really is quite humorous to see. Our chickens curtsey when they want us to pick them up and hold them. Normally, this is followed by some amount of petting and us telling them how good they are. Our birds truly are spoiled in grand fashion.
Since I didn't want to stop cutting the log up, I ignored the chickens and kept working. I felt that they would probably head back the other direction due to the noise of the chainsaw. So, it surprised me quite a lot to look up and see that they had gotten closer still. When they saw me looking again, they curtsied yet again—looking quite annoyed in a chicken sort of a way. I could almost see them huff and they were quite annoyed that their human just hadn't gotten the idea that they really needed to be picked up and told what good birds they were.
Not taking the hint, I decided to continue working on the log. Certainly, they'd get the idea this time and go in the other direction or possibly stop to watch me for a while (something that chickens do relatively often because they really are quite nosy). When I looked up the third time, the chickens had gotten dangerously close to my logging operation and I decided that I really must get them to safety. Seeing me look again, they not only curtsied, but squawked quite loudly in order to better attract my attention.
So, I shut my saw off and went over to the two birds. I picked a bird up in each arm (good thing there weren't three of them). Now, I'm walking down this rather steep hill, one chicken under each arm, hoping that I don't fall. All the while I'm telling the chickens what good birds they are. Eventually, I get to the coop and let them inside. I go inside with them and tell them what good birds they are again and give them some pets. At this point, I closed the run door, got the rest of the birds inside, and then went back to work.
Lesson learned? If your chickens really think they need to be petted and they take the time to curtsey, don't ignore them. I have to admit, they really did make my afternoon better. I laughed about their antics all the way back up the hill where I finished my log, loaded it into the cart, and dumped it down the chute. Feel free to share your favorite humorous chicken story with me at John@JohnMuellerBooks.com.
The Place of Automation in the User Interface
There was a time that a developer could rely on users to possess a certain level of technical acumen. That's no longer the case. Most of the people using a device containing a CPU today (I'm including PCs, laptops, tablets, and smartphones here) don't know anything about how it works and they don't care to know either. All these people know is that they really must have access to their app. (Some don't even realize the role data plays in making the app work.) The app can perform myriad tasks—everything from keeping track of the calories they've eaten to maintaining the scheduled events for the day. Devices that contain CPUs have become the irreplaceable partner for many people and these devices must work without much concern on the part of the user. In short, the device must provide a superior level of automation or the user simply won't know how to interact with it.
Of all the parts of a device that must be automated, the user interface is most important and also the most difficult to create. Users really don't want to have to think about the interface. Their focus is on the task that the app performs for them. In fact, some e-mails I've received recently about my Windows 8 book have driven home the idea that the app must simply work without any thought at all. It's because of these e-mails (and those for other books I've written) that I wrote the article entitled, "Designing Apps with Automation in Mind." This article points out the essential behaviors that applications must exhibit today to be successful.
On the other side of the fence, I continue to encounter an "old world" philosophy on the part of developers that applications should pack as much as possible into a small space—users will eventually figure out the complexity of the interface provided. Unfortunately, as users become more vocal in requiring IT to meet their demands, these approaches to the user interface will lose out. The next app is a click away and if it does the job of automating the interface better, your app will lose out. Even if there isn't another app to use, the user will simply ignore the app you've provided. The user will rely on an older version or simply not interact with the app if there is no older version. Many organizations have found out the hard way that attempting to force users to interact with an app is bound to fail.
The fact is, to be successful today, a developer must be part psychologist, part graphics artist, and part programming genius. Creating an acceptable interface is no longer good enough, especially when people want to access the same app from more than one device. The interface must be simple, must work well, and must automate as much of the input as possible for the user or it simply won't succeed. Let me know your thoughts about user interface automation at John@JohnMuellerBooks.com.
I was recently watching television and saw a commercial for a Weight Watchers app for mobile devices. In the commercial, a woman exclaims wonder about the new programs that Weight Watchers provides, which include this app for her mobile devices. To track her calories, she simply points her phone at the box containing whatever food she plans to eat and the app tracks the calories for her. The interesting part is that there is no data entry required. As technology continues to progress, you can expect to see more apps of this type. People really don't want to know anything about your app, how it works, or the cool code you put into it. They want to use the app without thinking about it at all.
Of all the parts of a device that must be automated, the user interface is most important and also the most difficult to create. Users really don't want to have to think about the interface. Their focus is on the task that the app performs for them. In fact, some e-mails I've received recently about my Windows 8 book have driven home the idea that the app must simply work without any thought at all. It's because of these e-mails (and those for other books I've written) that I wrote the article entitled, "Designing Apps with Automation in Mind." This article points out the essential behaviors that applications must exhibit today to be successful.
On the other side of the fence, I continue to encounter an "old world" philosophy on the part of developers that applications should pack as much as possible into a small space—users will eventually figure out the complexity of the interface provided. Unfortunately, as users become more vocal in requiring IT to meet their demands, these approaches to the user interface will lose out. The next app is a click away and if it does the job of automating the interface better, your app will lose out. Even if there isn't another app to use, the user will simply ignore the app you've provided. The user will rely on an older version or simply not interact with the app if there is no older version. Many organizations have found out the hard way that attempting to force users to interact with an app is bound to fail.
The fact is, to be successful today, a developer must be part psychologist, part graphics artist, and part programming genius. Creating an acceptable interface is no longer good enough, especially when people want to access the same app from more than one device. The interface must be simple, must work well, and must automate as much of the input as possible for the user or it simply won't succeed. Let me know your thoughts about user interface automation at John@JohnMuellerBooks.com.
