Checking for Mobile Friendliness

I’ve been writing computer books for over 29 years now and some people might think that’s long enough to know everything there is to know about computers. Actually, my involvement with computers spans over 40 years and I haven’t learned everything yet—nor will I. Every day is a new adventure, which is why I keep going. Besides the other projects I’ve been working on (which includes discovering the inner workings of both Near Field Communications, NFC, and machine learning), I’ve also been working through this whole concept of mobile device friendliness. In fact, I’ve discovered that there is actually a difference between sites that are mobile friendly and those that are mobile responsive, in that a mobile responsive design does a lot more for the mobile users (and is always mobile friendly by default).

During the time I wrote HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies, the concept of mobile development was still quite new. There weren’t any good tools for testing mobile friendliness. Consequently, both books do try to address the topic to a small extent (the extent possible at the time), but neither book says anything about testing. Fortunately, vendors such as Google are now making it possible for you to verify that your site is mobile friendly with an easy to use check. All you need to do is point your browser to https://www.google.com/webmasters/tools/mobile-friendly/, enter an URL, and click Analyze. You get a quick answer to your question as shown here within a few seconds.

Verify that your site will support mobile users by performing a mobile friendly check.
Output from a Successful Mobile Friendly Check

The page contains more than just a validation of the mobile friendliness of your site. When you scroll down, you see a simulated output of your site when viewed on a smartphone. The view is important because it helps you understand how a mobile user will see your site, versus the view that you provide to desktop and tablet users. It’s important not to assume that mobile users have the same functionality as other users do. Here’s the simulated view for my site.

Mobile users may see something different than you expect, even when your site is mobile friendly.
Verify the Smartphone View of Your Site

As more and more people rely on mobile devices to access the Internet, you need to become more aware of what they’re seeing and whether they can use your site at all. According to most authorities, more users access the Internet using mobile devices today, than other devices, such as laptops, desktops, or tables. If you don’t support mobile devices correctly, you lose out on the potential audience for your site. This means that you may make less money than you otherwise could from sales and that the influence of your site is far less. Let me know your thoughts about mobile device access at John@JohnMuellerBooks.com.

 

New Look! New Features!

If you’re visiting my blog for the first time this year, you probably noticed a few changes in its appearance. Sometimes a site changes its appearance simply to provide a different look—to enhance its aesthetic appeal. It’s true that I had used the previous design for a number of years, but that’s not the reason for the changes you see today. These changes come as the result of input from the people who read my blog and took the time to comment on it.

The biggest change is one that you can’t readily see until you access my blog from a smartphone. My site now works well with devices of all sizes so that you can gain access to the information my blog provides from any location using any device. It took me a while to find a theme that I thought would preserve most of the look and feel of the original blog, but allow for this added functionality. Even though the feel is a little different, the addition of this feature is important to enough readers that I really want it to work well.

As part of making my blog easier to use, I also went for a cleaner look. The new format should work in a wider range of settings, even in bright sunlight (as well as anything works in bright sunlight). The larger type should also make it easier for people with special visual needs to see. I tested the new setup out on a number of monitors and find that it scales better than the old design too.

Part of the update also affects my web site. I wanted to provide better consistency between the two locations. Some viewers said it was a bit disconcerting to use one layout on the web site and another on the blog. My original intent had been to provide the best layout for each setting, but this method of configuring the two locations didn’t work nearly as well as I thought it would.

Of course, I always want your input because this site is specifically designed to meet your needs. I want the readers of my books to get maximum benefit from them, which means having a blog that actually meets those needs. If you see what you like or want to express concerns about issues you don’t like, please feel free to contact me at John@JohnMuellerBooks.com. As always, your input is essential to the success of my books, my blog, and my other endeavors!

During the upcoming months I do plan to make additional changes. The blog has gotten a bit unwieldy, so I plan to remove some existing content to make room for new information. I’ll also be adding more linkage between my web site and the blog so that the two work better together. Your patience during this time of transition is greatly appreciated!

 

Use of the title Attribute

I try to keep up with accessibility issues so that the content I provide is always as friendly as possible. With this in mind, I’ve used the title attribute for links and wherever else it might be needed for many years now. At one time, the title attribute was actually mandated to make pages accessible by organizations such as the World Wide Web Consortium (W3C). The attribute also makes an appearance in a number of my books, such as Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements with full documentation as to the benefits of using it.

However, today I find myself having to take a new direction and actually tell people not to use the title attribute because it could potentially make pages less accessible. Part of the reason that the title attribute isn’t used anymore is that some people became confused about it and started using it for Search Engine Optimization (SEO) uses and that was never the point. A lack of browser support and all sorts of other issues added to the demise of the title attribute as a useful link feature. The point is that there is a reason for the title attribute, but no one was using it and people with special accessibility needs found ways around it. At one point, the screen readers I used actually did make use of the title attribute, but newer screen readers don’t. In fact, the new approach is to ensure that links contain enough text to ensure someone with a screen reader knows what they mean. It’s a situation where a specific programming technique didn’t get the job done so another technique is now in use—one that seems more natural and that people are actually using.

So, what cued me into the fact that the title attribute is no longer particularly useful? Well, I use WordPress to create blog posts and noted recently that they had removed the title attribute from the dialog box for creating links. For a while I was adding the title attribute in by hand because I really did feel I was making the page more accessible. However, after talking with a friend about the issue and experimenting with the latest screen readers myself, I find that the title attribute is one of those “also ran” features that simply doesn’t see use often enough to make it worthwhile using. The new strategy is to ensure you provide enough text as part of your link to ensure the link is clear all by itself (even if you need to hide part of that text from view). If you have a copy of one of my books that espouses the use of the title attribute, make sure you change your practice to match what the rest of the world is doing today. Let me know if you have any questions about the use of the title attribute at John@JohnMuellerBooks.com.

 

Avoiding Graphical Pokes in the Eye

There are times when you can truly say that something isn’t better than a poke in the eye. Using too many of the wrong sort of graphics on a website is one of those times. Some sites use graphics in such a way that it really does feel like a poke in the eye after a while. You end up with sore, tired eyes after viewing the site for only a few minutes. Sites like this is of the reasons I wrote Zapping Graphics that Dazzle Too Much. The article helps you avoid the sorts of graphics that actually make your site a place not to visit. More importantly, the article provides you with specific techniques for creating truly amazing graphics that dazzle in the right way.

Graphical pokes in the eye are bad for the user, but they’re also bad for you because they give users a good reason to avoid your site. Users get to the point of wanting to receive a service or buy products at any other site they can find online. After a while, your site just sits there being viewed by the few people who stumble upon it after clicking a link in a search engine. If things get bad enough, even search engines will place your site so far down the list that no one will find it.

The fact is that there isn’t really a good reason to have unacceptable graphics on any site. There are resources online (see my article for details) to help you create better graphics, even if you can’t rely on a graphic designer. However, if you’re betting the business on the viability and acceptability of your site, then the cost of a graphic designer is probably a lot cheaper than the cost of failure. An essential truth for anyone creating a website today, especially one that sells a product or service, is that the next site is only a click away. Business owners have always had to keep track of the competition, but doing so is even more critical now because a competitor can easily outclass you with just the right presentation.

Don’t get the idea that great graphics are only useful to businesses either. Creating applications today usually means working within a Web-based environment now. In order to create an application that employees or other users will actually enjoy means developing and using engaging graphics in the right way. Applications, even great applications, can fail miserably when users refuse to employ them to perform useful work. When that happens, you could find yourself out of a job.

Most developers really don’t have a lot of graphic design experience. The few who do are in high demand. Building some graphic design skills will make it easier to find employment in today’s competitive environment. Your applications and websites will be successful because they attract the right kind of attention. Let me know your thoughts about the role of graphics in the business environment today at John@JohnMuellerBooks.com.

 

Guessing At What Your User Wants Doesn’t Work

Web-based applications seem determined to embrace a form of automation that really doesn’t make a lot of sense and it’s causing more than a little woe for end users. Personalization, the act of guessing what a user wants based on previous activity, is a serious problem. At one level, personalization is actually costing vendors sales. For example, because of my previous searches on Amazon, I couldn’t find a product I really wanted. Amazon kept suggesting items I didn’t want or need. I ended up buying the product on another site and only later found I could purchase it on Amazon for less money. (Not to pick on Amazon too much, I have the same sorts of problems with other sites such as Google.)

Adding personalization to an application is supposed to help a user find items of interest, but we often need to search for something other than the usual item or may not even know what we want. In these situations, personalization actually gets in the way. A recent article, “Personalization is collapsing the Web” expresses the idea clearly by pointing out that people are sometimes ill-informed about current issues because personalization hides relevant news from view. The problem is so prevalent that it now has a name, the filter bubble, as described in “Content Personalization: How Much Is Too Much?” Users can’t find the information they need and vendors are losing sales due to the filter bubble created by various search engine vendors such as Microsoft (in Bing).

In order to provide personalization, sites must track your every move. It isn’t just the National Security Agency (NSA) that snoops on you, but just about everyone else on the Web as well. To some extent, any suggestion that you have any privacy on the Web is simply unrealistic. However, there comes a point at which the snooping, categorization, and misinformed suggestions get to the point of ridiculous and savvy users start searching for alternatives. One such alternative espoused by writers such as John Dvorak is DuckDuckGo. At least it doesn’t track your every move or provide you with suggestions that you don’t need. The prying can even take odd turns, such as the woman who was arrested for researching a pressure cooker on Google.

Guessing, even if the guessing is informed by previous activity, usually won’t work for an application. In fact, it’s probably a bad practice for a lot of reasons. Here are the things that you should consider when thinking about adding personalization to your application.

 

  • Guesses are usually wrong because few personalization engines can actually understand user needs successfully.
  • Personalization can cost an organization money by hiding products, services, or information that a user really needs.
  • Wrongful suggestions reduce the confidence the user has in the application.
  • Tracking the user makes the user feel spied upon.
  • Time and resources required to track a user and offer personalized suggestions could be better spent by making the application faster, more reliable, and more secure.


Odd as it might seen, I have never yet encountered a situation where personalization was an aid to anything other than making me leave the site for a location that isn’t personalized. When viewing a news site, it’s better to see the top stories of the day and drill down into the less sensational stories as needed. In most cases, what I really need is a good search engine that helps me find what I want, once I know what it is. Let me know your thoughts about personalization at John@JohnMuellerBooks.com.

 

Finding Math Libraries for Your Next JavaScript Project

Finding precisely the JavaScript math library you need can be difficult. In both HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies I define a need to perform math tasks accurately. Both books provide some workarounds for the inaccuracies inherent in performing floating point math. It’s important to remember that some numbers can’t be represented properly in the decimal system used by humans, that there are other numbers the computer can’t represent accurately in decimal, and that there are also error present in converting decimal numbers to binary and vice versa. In short, there are a number of levels at which math errors can occur. Yes, it’s true that the math errors are small, but they become a concern when performing large calculations, some of which can’t suffer any level of error (such as plotting a course to Mars).

The problem is so significant in some cases, that trying to work around the issues becomes an application development task in its own right. It’s for that reason that I started looking for math libraries to perform certain tasks. After all, it’s a lot easier to let someone else do the heavy lifting when it comes to a complex calculation. You can read about the results of some of this research in my article entitled, “Four Serious Math Libraries for JavaScript.” The article not only details the source of many of these errors in great detail, but reviews four libraries you can use to solve them.

The important takeaway I got from the research is that, like many programming tasks, there is no one library that does it all. Each library had something to recommend it. However, each library was sufficiently robust that you shouldn’t need to combine them to create your application. The point is to choose the one library that best meets your needs.

I’m actually looking into a number of library types for use in JavaScript programming. The advantage of JavaScript is that it does provide incredibly strong community support in the form of libraries that you simply use as needed. What sorts of issues do you encounter when writing applications using JavaScript. Let me know what kinds of libraries that you’re having a hard time finding at John@JohnMuellerBooks.com. I’d be more than happy to perform the research for library types that receive enough reader support and report my findings to you.

 

Web Page Units of Measure

Creating a Web page usually involves placing elements on the page in such a way that the viewer sees the content in a manner that makes sense. In order to obtain this presentation, you must describe element placement in a manner the browser understands using one of several units of measure. HTML5 Programming with JavaScript for Dummies, CSS3 for Dummies, and Web Matrix Developer’s Guide all discuss units of measure to some extent. However, readers have asked me to explain the units of measure in a little more detail.

Some units of measure work better than others do in obtaining a specific result. For example, when you specify placement in pixels (px), you tell the browser to define element placement with regard to the physical units of a display. This is the most precise, yet least flexible, method of defining units of measure. In addition, it can create issues with mobile devices because these devices typically don’t offer that many pixels of display area and may not allow scrolling of information that doesn’t appear in a single screen (the part that appears to the right and toward the bottom of the page).

More flexible units of device-specific measure include the inch (in), centimeter (cm), and millimeter (mm). In this case, the browser converts the measurement to pixels using the device’s conversion metric. For example, a typical PC display uses 96 pixels-per-inch. However, the user can change the metric so that an inch could consume 120 pixels instead (making the elements larger than normal). Whether this flexibility solves the problem of working with mobile devices depends on the mobile device and the metric it uses to convert physical units to pixels.

Besides device and physical measures, you can also use printer’s measures that include the point (pt) and pica (pc). These units of measure theoretically work the same as physical measures because a point is 1/72nd inch and a pica is 12 points (or 1/6th inch). In reality, it’s possible that a browser will convert the units of measure based on the size of the fonts that the device uses. However, you can’t count on this flexibility and must assume that these printer’s measures are simply a different kind of physical measure.

Fortunately there are two units of measure that are guaranteed to reflect the size of a font on the display. The em is a measure of the actual font size. One device may use a 12 point font while another device uses a 10 point font. An em will equal 12 points on the first device and 10 points on the second device without any modification of the code on your part. This feature makes the page quite flexible and usable with any device. The other unit of measure is the ex, which is the measure of the x-height of a font (the median of all of the characters in a particular letter set). As with the em, the ex automatically scales to consider the point size of characters used by a particular device.

All of the units of measure so far are absolute. You place elements on a screen in a precise position. Modern Web design dictates that pages employ Responsive Web Design (RWD) to ensure that the page will work on any device. A part of RWD is to use relative placement wherever possible so that the page and its elements automatically resize to meet the needs of a device. You use the percentage (%) unit of measure in this case, where an element uses a percentage of the available space, whatever that space might be. Of course, this approach means that all devices see the entire page. However, a disadvantage of this approach is that the elements might be so small on some devices as to make them unusable.

What are your thoughts about units of measure? Which do you use most often? Let me know at John@JohnMuellerBooks.com.

 

HTML5 and CSS3 Bugs in iOS 7

Several readers have written to ask about an article that appeared in InfoWorld entitled, “Bad news: iOS 7’s HTML5 is full of bugs.” In reading about the bugs, it doesn’t appear that any of them will affect the examples found in either HTML5 Programming with JavaScript for Dummies or CSS3 for Dummies. Unfortunately, I don’t personally own a copy of iOS 7 to perform any testing to verify that there aren’t any problems. A helpful reader did test a few examples for me and didn’t report any errors. If you find that you’re having problems with any of the examples in either book, please let me know at John@JohnMuellerBooks.com.

This issue does serve to point out a problem that I’ve encountered more than a few times in supporting my books. A vendor can release a faulty version of a library, operating system, or other support software required for my books and it will appear that the examples are buggy to the reader. If you read about these sorts of issues, please let me know about them so that I can test the book examples and report back to you here.

 

Obtaining an Editor for Your Web-based Application

One of the things I like most about writing code for Web-based applications is that there are so many libraries out there to make the task simple. You can stitch together libraries to create an application in only a small amount of the time required to create the same application in desktop form and the resulting application is going to be a lot more flexible. (Admittedly, the desktop application is usually prettier and can be faster.) Some time intensive tasks for desktop developers, such as creating an editor, require little or no work when creating a Web-based application. In fact, you can get a number of editors for free as described in my article, “5 Free JavaScript Libraries to Add Text Editing to Your Web Application.”

In this case, I wanted to see what was available in the way of editors. There are quite a large number of editors out there, some paid, some not. After discovering that the scope of my original article idea was too large (just editors in general), I decided to narrow the scope to just those editors that are free. After all, why pay for something you can get free unless you actually need the special features of the paid product?

Unfortunately, I still ended up with too many editors (somewhere in the neighborhood of 20). So, I decided to categorize the editors by complexity and presentation. I ended up with five major categories that span the range from simple to complex. The article contains what I think are the five best editors. Of course, your opinion may vary from mine. The point is, that you have a significant number of editors to choose from, so there is absolutely no reason to ever write code to create your own editor unless you need something truly specialized.

I’m thinking about other sorts of classes of application module for future articles. For example, it might be necessary to create an application where the user can make a simple drawing to show how something is put together or how something has failed. I actually needed such a module when trying to describe the glass panes used in the front of my wood stove not long ago and finally resorted to using paper and faxing it. The graphics module would have been easier, faster, and simpler.

What sorts of modules do you need for your Web-based applications? I’m always looking for good ideas from the people who read my material. Send me your thoughts at John@JohnMuellerBooks.com.

 

Review of HTML5 Step by Step

Microsoft has thrown developers yet another curve—Windows 8 will rely on HTML5 and JavaScript for a programming interface. The revelation has many developers horrified. For me, it means updating my HTML and JavaScript skills, which was one motivation for reading the book reviewed in today’s post. HTML5 Step by Step, written by Faithe Wempen, provides a quick method of getting up to speed on HTML5.

This book is designed to aid anyone who wants to know how to work with HTML5, which means that it starts out extremely simple. The book avoids the ever popular Hello World example, but the example it does provide is small and easily understood. The chapters don’t remain simple, however, so even if you have some experience with HTML, you can use this book to update your skills. You’ll likely want to start around Chapter 3 if you are experienced and skim through the material until you come to something unfamiliar, which could happen relatively fast given the changes in HTML5.

HTML5 Step by Step is light on theory and reference information, but heavy with hands on experiences. It relies on using Notepad as an editor, which may seem like an odd choice, until you read the “Why Learn HTML in Notepad?” section of the Introduction. The author’s reasoning is akin to the same reasoning I would use, which is to make sure that the reader types everything and understands why a particular element is required. If you really want to get the most out of this book, you have to do the exercises in Notepad as the author suggests. Otherwise, I guarantee you’ll miss out on something important. Faithe has made a great choice of teaching aids in this case.

Chapter 1 is most definitely designed for the rank novice. It even shows how to set up the examples directory as a favorite in Notepad. However, unlike many books, the rank novice should read the book’s Introduction because Faithe does provide some needed information there, such as the “Understanding HTML Tags” section.

Chapter 2 gets the reader started with some structural elements. Faithe covers everything that the reader is likely to need for a typical starter Web page. I wish that the chapter had covered <meta> tags in a little more detail, or at least provided a table listing them, but this book does have an emphasis on hands on exercises, so the omission isn’t a glaring one. As an alternative to including the information, an update could provide a URL that lists the tags so the reader knows where to go for additional information.

By Chapter 3, the reader is formatting text and starting to make the sample site look pretty. I really thought Faithe did a nice job of moving the reader along at a fast, but manageable pace. She shows the reader how to make effective use of tag combinations, such as the <kbd> (keyboard) and <b> (bold) tags.

There is the smallest amount of reference information in some chapters. For example, Chapter 4 contains a table on page 50 showing the list attributes. These references are very small and quite helpful, but the reader should understand that the emphasis is on doing something and that the reference material may not be complete. For example, the special symbols table on page 56 is missing the em dash, which is something most people use.

The book progresses at a reasonable pace. Never did I find myself rushed. The examples all seem to work fine and I didn’t find missing steps in the procedures. The author uses an adequate number of graphics so that the reader doesn’t get lost. I liked the fact that every exercise ends with a cleanup section and a list of the major points that the reader should have gotten from the exercise.

Readers who are only interested in new tags will need to wait until Chapter 9 to see one. The <figure> tag makes an appearance on page 141. However, even some professionals didn’t use all of the HTML4 tags and it really does pay to start at Chapter 3 and look for something you don’t recognize. It may surprise you to find that an earlier chapter contains a somewhat new (but not new to HTML5 tag) that you’ve passed by.

There are a few nits to pick with this book. The first is that the author places the accessibility information in an appendix where almost no one is going to read it. The information should have appeared as part of the rest of the book as appropriate. In addition, the author misses the big point that most people today have some sort of special need addressed by accessibility aids. The number of people who are colorblind alone is 8 percent of the male population and 0.5 percent of the female population. This book is unlikely to help you create a truly accessible sitenot that this is the reason you’re buying the book.

The second is that Appendix C doesn’t really help very much with the additions and subtractions for HTML5. For example, Appendix C doesn’t tell you about the new <aside> tag. If you want a quick list of the new tags, check out the www.w3schools.com HTML5 New Elements page. (I checked the missing <aside> tag against a number of other sites, such as About.com.) The point is that Appendix C won’t give you the complete picture. Again, this isn’t one of the selling points of the book, but the list should have been complete.

The third is that there isn’t really enough information about why something is done or why it changedsimply that it must be done or that it did change. The reader probably doesn’t want a full blown history of the change, but the why of something can make understanding and, more importantly, remembering a concept easier. Still, this particular nit is minor since the purpose of the book is to get you started with HTML5 quickly and not to explore it at a theoretical level.

Overall, HTML5 Step by Step is a great book for the novice who wants to learn how to create Web pages. It’s also an acceptable book for someone who’s experienced with HTML coding, but wants to get up-to-date on the HTML5 changes quickly. This book is definitely designed for someone who wants to do something, rather than simply read about it. If you don’t perform the exercises, you won’t get much out of the book.