• About This Newsletter
• What Are You Thinking? => Using JavaScript
• On the Web => Amazon Silk: A New Mobile Browser
• On the Web => Steve Jobs and Dennis Ritchie, in Memoriam
• On the Blog => Why There Are Few (No?) Good JavaScript Books
• Q&A => Could You Explain File Permissions?
• What is Larry Thinking => Sexism and Bad User Interface
• Book Giveaway => “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th Edition)
• Larry Ullman’s Book News => “Modern JavaScript: Develop and Design”

About This Newsletter

Life is busy here and I’m well behind schedule on all fronts, so this newsletter is getting out about a week to ten days late. I’m taking consolation in the fact that I’ve kept pretty close to a three-week schedule for the past year (about 15 newsletters sent in that time). Rather than blather on, let’s get on with the show!

As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!

What Are You Thinking? => Using JavaScript

So I’m working on my next book, “Modern JavaScript: Develop and Design.” As I write about in a blog post (also mentioned later in this newsletter), JavaScript is kind of a tricky language to write a book about, as a lot of information is required just to do a basic thing such as form validation. Like any of my books, I’m working hard to use lots of good, real-world examples to demonstrate the new information being taught. Thus far, with two real code chapters in the bank, most examples are based upon form validation and data manipulation. These are obviously crucial uses of JavaScript, and good ways to practice some of the early material. Some readers have let me know that they’re hoping to see lots and lots of examples, so I thought I’d go ahead and send a direct request out asking what, if any, specific examples or topics you’d like to see in the book. What do you know you need to use JavaScript for? What are you curious about? What have you seen that you know is confusing to you and you’d like clarification on?

All thoughts and suggestions are welcome and very much appreciated. As an incentive, I’ll go ahead and give away ten copies of “Modern JavaScript: Develop and Design” to people with the best responses.

On the Web => Amazon Silk: A New Mobile Browser

As you may have seen, Amazon announced their new lineup of Kindles recently, from the $79 base version to the $199 Kindle Fire, a rival to Apple’s iPad. One thing that piqued my interest about the Kindle Fire is that it includes a new, custom Web browser, named Silk. Amazon posted an introduction to Silk, along with a six-minute video, on their site, too. A lot on that page and in the video is marketing hype, but they raise some interesting points about the fact that Web browsers are fundamentally the same as they were 15 years ago, and aren’t ideal for today’s use, especially with all the mobile devices. Now the solution they came up with seems to be something akin to a reverse CDN: Whereas a CDN takes the load off of one server and shares it across a network of servers, Amazon Silk uses Amazon Web Services (AWS) to reduce the load on the device. From just what I’ve seen, it doesn’t seem like they’ve addressed a problem with browsers, but rather with the HTTP protocol, introducing their own gateway to improve the communications. It’ll be interesting to see what impact this new approach has, and how, if at all, it affects Web development in the years to come.

On the Web => Steve Jobs and Dennis Ritchie, in Memoriam

As I’m sure you’re all aware, Steve Jobs, one of the founders of Apple, passed away just recently. You may also know that I’m a pretty big fan of Apple. I first learned to program Basic on an Apple IIe, the first computer I purchased was a Macintosh Color Classic, and I’m probably on my 10th or 12th Mac by now. I’m not saying Macs are better than PCs, and they’re certainly not cheaper, but I definitely prefer them. A lot has been said and written about Jobs since his passing, such that I have little to add, except I would offer that I what I think was the most brilliant thing that happened during Jobs’s tenure was the ability to get non-Mac people to buy Apple products. For decades, if you purchased an Apple product, you were buying either a Mac or Apple software to run on a Mac. This accounted for at best about 5% of the computing population. Thanks to the iPod, iPhone, and iPad, almost all computer users and a majority of mobile phone users have one or more Apple products, whether or not they ever bought an Apple computer (and many of these people have since started buying Macs, too). Just brilliant, and the clear reason why Apple has become one of the most valuable companies in the world. Had you told me 15 years ago that Apple would become a dominant computer company and Bill Gates a prominent philanthropist, I wouldn’t have believed you.

Jobs’s other huge success was with Pixar, although he probably had less directly to do with Pixar’s success than the brilliant talents employed there. Jobs purchased what became Pixar from George Lucas, helped build it up, and when Pixar was purchased by Disney, Jobs became the single largest shareholder of Walt Disney. Quite the life. If you’d like one more little blip about Jobs, check out his Stanford commencement address from 2005. In it, Jobs talks candidly about work, life, and death.

Days after Steve Jobs passed away, Dennis Ritchie died, garnering much, much less media attention. Dennis Ritchie arguably had a bigger impact on computing and the world than Jobs, but is no household name. If you’re not familiar with Ritchie, all he did was create the C programming language, and helped develop the Unix operating system. C is one of the most important programming languages of all time. It has greatly influenced many other languages, and is still used widely today. In fact, PHP, Python, and Perl are all written in C! Unix, and its inspired variants such as Linux, is running most of the Internet, along with Apple’s iOS devices, Tivo’s, and many other devices.

On the Blog => Why There Are Few (No?) Good JavaScript Books

Just yesterday, I posted a blog article discussing my thoughts on why there are so few good JavaScript books. In part this post stems from time spent skimming through other JavaScript books and thinking “Really, you’re doing that in this book?” And, in part, in formally writing a JavaScript book now myself, I’m aware of some of the unique challenges that JavaScript poses for writers.

Q&A => Could You Explain File Permissions?

File permissions and file paths are probably two of the things that I get the most questions on, and that beginners are most often confused about. Some time back, Martin had asked if I’d explain file permissions, and even though a previous newsletter touched upon the subject, it’s worth going into again and in more detail. For a couple of reasons, I’m going to ignore Windows permissions and focus on *nix, which includes Unix, Linux, and Mac OS X. First, all these operating systems share the same permissions scheme. Second, statistically, most Web servers are running one of these operating systems. Third, permissions in Windows rarely need to be altered or cause problems, in my experience. And, fourth, you’re much more likely to be confused by *nix permissions, which are as follows…

File and folder permissions are an operating system’s way of dictating who can do what to that file or folder. There are three permissions that can be granted or denied: read, write, and execute. For files, read means the ability to literally open and read the file; write means the ability to modify the file; and execute means the ability to run the file (e.g., as an executable or a script). For directories, read means the ability to see the names of the files in the directory; write means the ability to modify the directory (such as create, rename, or delete files and folders therein); and execute means the ability to traverse the directory (i.e., be able to go into it). You’ll see these permissions represented by both letters—r, w, and x—and octal (base-8) numbers: 4 (read), 2 (write), and 1 (execute). These numeric values correspond to bits, meaning that different sums from 0 to 7 represent unique permission combinations. For example, 5 has to be read plus execute; 6 has to be read plus write; and, 7 is all three (5, 6, and 7 are the most common permissions digits you’ll see).

Now for every file and folder, these permissions can be set for three types of users: the owner, the owner’s group, and everyone. For example, on a Web server, you may have an account under the username trout. Your username will also be associated with a group, such as clients. Other people with accounts on the same server will have different usernames but may be part of the same group. There will also be other groups, such as staff or mysql. The permissions on any file or folder can be set as three octal digits, where the first digit represents the owner’s permissions, the second represents the owner’s group’s permissions (i.e., the permissions for other people in that group), and the third digit represents the permissions for everyone else. 644 permissions mean that you can read from and write to that file or folder, while everyone else can only read from it. Written using letters instead of octal numbers, you’ll see a file or folder’s permissions represented using 10 characters: the first reflects other details about the file or folder (I won’t get into that here); the next three are for the owner’s read, write, and execute permissions; the next three for the owner’s group’s read, write, and execute permissions; and the last three for everyone’s. Thus, the octal 644 becomes -rw-r–r–. The octal 755 is -rwxr-xr-x.

So there are the basics and the hieroglyphics you’ll occasionally see; what does this mean in actual application? For starters, you need to understand that the third category—everyone else—means everyone else on the computer, not everyone else in the universe. For example, if you create a directory with open permissions—777 or -rwxrwxrwx, that doesn’t mean anyone with an Internet connection can modify that directory’s contents. No. You can only modify a directory’s contents if you have access to the server’s file system, which means you’ve connected to the server via FTP or command line (SSH, telnet) access. And that kind of access requires using an account recognized by the server. But what about loading a Web page in the browser? Well, that is a type of server access, but not file system access. When a user goes to a Web site in the browser, the user isn’t interfacing with the server’s file system, but actually with the Web server software, such as Apache. Apache then does the actual accessing of the file system. So don’t fret that assigning open permissions to a file or directory means that anyone in the universe has access. That’s not the case.

But it is the case that an open file or directory on the server is accessible by any valid user on that server, assuming that other restrictions are not in place and that the user knows about its existence. For examples of restrictions, PHP can easily be limited as to which directories it can access and which it cannot. The same goes for Apache. In fact, the biggest security concern isn’t that people can access and manipulate your files and folders, but rather that software running on the server can. And this is where you have to be careful. Many hacks take advantage of security holes in scripts or applications to make Apache and PHP—the software already running on the server—do something malicious. All things considered, this doesn’t mean you should be cavalier about assigning open permissions, but it does mean that it’s not out-and-out irresponsible to use them when needed. Speaking of which…

The last real-world issue you’ll come across, which is a big complication for many, is establishing the correct permissions to allow for file uploads, or for PHP to write a text file, and the like. When you upload files to the server using FTP, or even create a directory using FTP, the owner of the uploaded file or folder will be you. The PHP script that needs to write to that text file or directory (in this case, “write” means to modify the directory by moving a file into it), will be running as a different user, namely the user that the Web server software (e.g., Apache) is running as (Apache commonly runs as “nobody”). In order for PHP to do what it needs to do, permissions need to be modified so that the Apache user can write to it. Normally this means using 755 as the permissions.

If you do need to create open directories and files, there are ways you can improve the security of using them, most of which I highlighted in that previous newsletter. For starters, always try to put these directories outside of the Web root directory, and then use a proxy script to safely fetch the contents. By doing so, you’re able to mitigate the increased security risk of having open directories and files by adding a layer of protection against accessing the content therein.

What is Larry Thinking? => Sexism and Bad User Interface

About fifteen years ago, when I was working at Borders bookstores (RIP), a co-worker got married. Afterward, she was talking one day about how she had gone into her bank to add her new husband to her account. The bank added her husband to the account and let her know that her husband would have to come in and authorize her before she could access the account herself. Wait, what? Yes, she went in, added her husband, and was no longer able to use the account that only moments earlier had been hers. This is because the bank’s policy was for men to be the primary account holders. As soon as her husband was added to the account, it became his account. This is just a lovely bit of institutional sexism, I think, especially when you consider that I’m talking about the mid-1990’s here, not 1950! I do not know what happened beyond that—I would hope she’d change banks, but beyond the sexism, it amazed me that a system was in place in which a person has the power to disempower themselves. A very strange concept.

My wife works in the field of education, which in the United States is known for many things, among them having broad, institutional dictums imposed upon schools and faculty. A frequent cause of problems is the software people are forced to use. Having software forced upon you is a hazard all employees face, but given the situation of public schools, such software is inevitably created under the worst of all possible situations:

• The software needs are identified by a committee of people, none of whom will actually be using the software.
• Undoubtedly a requirement is that the software can run on old, outdated computers.
• The budget will be tight.

Take these three things together, and you can plan on getting software that takes way too long to complete, that will be outdated and impractical upon its released, and that will be used for far too long from there. This sounds jaded, perhaps, and I’m certainly exaggerating some, but this is essentially the situation the American education system, if not the entire American government, is in when it comes to developing custom software.

The reason I’m thinking about this now, is that my wife was using one of these less-than-ideal applications the other day. The application itself is kind of like project management software and she was responsible for maintaining a project’s particulars through this system. Due to a lack of good documentation, she had misidentified her role on the project (within the system) and went back in to change her role. She selected what she thought was the right role for her account on that project and ended up removing her own administrative ability to manage the project. In other words, she locked herself out, and she was ostensibly the project manager! Again, why would someone create the ability for an administrator to de-administer themselves? And, what’s worse, absolutely no warning was given to my wife (i.e., the user) that this would be a consequence of the action about to be taken.

By comparison, my role on a project was just turned over to someone else, and part of that project involved making use of Amazon’s resources. Amazon, which I feel generally does everything right, did not allow me, the administrator, to just remove my name and email address from the system, thereby shutting out anyone’s access. Instead, to make the switch from me to this other person, I had to add her to the system and give her administrative access. She, then, could go in and remove my administrative access. Was this a bit more complicated? Yes. But it was the right way to handle this scenario and it worked without problem.

This, then, is a call to you: the next time you’re working on a Web site or application, think about the user interface and make sure it makes logical sense. Write the functionality so that administrators cannot disable their own access to the system. And include great documentation, and provide many, clear warnings when actions are about to be taken that are permanent. Oh, and if you’re running a bank, how about letting a person know that she is about to be blocked out of her own account? Or, you know, just make your policies less sexist.

Book Giveaway => “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th Edition)

As I expected, there was a wonderful response to my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th edition) giveaway. Unfortunately, I haven’t yet had the time to respond to everyone, or really anyone. For this I apologize, and I hope to do that within the week. So if you wrote in hoping for a book, rest assured that just because you haven’t heard from me yet means you won’t be getting a copy (conversely, it doesn’t mean you necessarily will, either). What really happened is that I’m just swamped. Apologies again!

I’ll be able to give away a few more copies of this book in a future newsletter.

Larry Ullman’s Book News => “Modern JavaScript: Develop and Design”

I just submitted Chapter 5 of “Modern JavaScript: Develop and Design”, which means I’m about 30% done with the first draft (well, first submitted draft: there are multiple internal drafts prior to that). Progress is going more slowly than I’d like, but I’ve had sick kids and other personal issues making it harder to get to work. I always hope I’m about to turn a corner and speed up. One of these days, I will!

The first three chapters cover Part 1 of the book, which represents the fundamentals of JavaScript. Chapter 1 is a bit of an introduction to JavaScript overall. Chapter 2 provides a sneak peak at how JavaScript is used in a Web browser. Chapter 3 discusses and demonstrates several tools you’ll want to use.

The second part of the book is the heart of JavaScript as a true programming language. Chapter 4 covers simple data types (numbers, strings, and Booleans). Chapter 5 is on control structures: conditionals and loops. Now I’m turning to the fun stuff, and the topics that differentiate JavaScript from other languages. This includes objects (Chapter 6), functions (Chapter 7), events (Chapter 8), and the browser (Chapter 9). Hopefully by the next newsletter I’ll have those four chapters written. Hopefully!

This rule comes into play in many ways, from where navigation elements should be located, to how buttons and links behave. It also means that you shouldn’t “break the browser” by attempting to disable JavaScript features (such as Control+Clicking or Right+Clicking on an element), preventing use of the back button, and so forth. This last issue—wanting the user not to use the back button—is a big mistake. (And keep in mind that most attempts to circumvent common browser behavior can be easily circumvented by disabling JavaScript.)

Fortunately, you can have your proverbial cake and eat it, too. This is to say, there are ways to accomplish your goals without undermining standard user or browser behavior. For example, if it might be a problem if the user clicks the back button, write the site’s code to address that possibility (sessions can be used towards that end). As another example, if you don’t want the user to copy images, well, that’s a tougher one. You can use JavaScript to prevent that, but JavaScript can be disabled. You can embed the image in Flash so that it’s not directly copy-able, but the user could still take a screen shot. The fix is simple: add a watermark to the images, when necessary. With any possible example, the main idea is this: when something a user, or the browser, might commonly do could be a problem for your site, program the site to handle that possibility. Whatever you do, don’t try to prevent the user from doing something their accustomed to doing on every other site they visit. If you take that approach, all you’ll succeed in is driving away your visitors.

1. Prevent, Don’t Scold
2. Give Immediate Feedback
3. Let the User Work
4. Innocent Until Proven Guilty

The first rule ties in nicely to a post I just wrote on putting the user in a place where they can succeed. I don’t want to waste time here re-iterating what’s said there, but give it a read—at least that part about best practices—and keep that perspective in mind the next time you go to design a user interface.

I fill out the form properly, I thought, then click submit. At that point I see a message about my chosen password being invalid because it didn’t contain both upper- and lowercase letters, plus at least one number. That’s a fine requirement, of course, but why didn’t the registration form indicate those requirements? It’s obvious that an email field needs a valid email address, but if you’re developing a site and you know that you’re going to validate a field to confirm that it includes both upper- and lowercase letters, plus at least one number, how about telling the end user that, too? So here’s the first, most important rule of a good user interface:

A proper user-interface sets the user up to succeed.

Whether you’re designing a Web site, managing a group of people, or being a parent, you have to put your users, employees, and children in a place where they can do things well. And by “well”, I mean: they can do things they way you think they should!

Conversely, I just finished doing my United States taxes, which I always do online using TurboTax. I use TurboTax primarily because the user interface is extraordinarily well done. For example, it’ll ask you a seemingly random, strange question, like “Did you roll over the proceeds from a farming operation into a non-work-related 403b?” I might look at that and go “huh?” but one great thing TurboTax does is add parenthetical notes like “This is not common.” Simple and brilliant. And TurboTax has other nice features, like indicating where you are in the process, reviewing the data you’ve entered, and so forth, but the clear messages—right where I’m focusing at that moment—make it easy for me to use the system properly.

It can be tricky for developers, who are theoretically quite knowledgeable about computers, to put themselves in the mindset of an end user, but there here is one simple way to create a successful user-interface: look at what you’re doing on the server side of things. If you’re going to check a password field for a number, put a message on the form saying a number is required. The same goes for a length requirement. If a date will be validated against a given format (like four digits for the year), have the form indicate the proper format, too. The same goes for phone numbers. If a username can’t contain a space, say as much. Set the user up to succeed instead of making them feel stupid for not doing something they weren’t told to do in the first place!

An HTML form should…

• Provide good instructions. Indicate to the user what they should do, what will happen next, etc.
• Clearly indicate which fields are required. Use of asterisks, bold font, or a different font color is the standard. Also have a note that indicates that these formatting changes mean the fields are required.
• Explain why specific data is being requested. This is particularly important, as you want to make the user comfortable when providing their personal information. If you’re asking for anything sensitive or just somewhat unusual, make sure you include the reason why. It’s also a good idea to let the user know that their personal information–email address and phone number, in particular–won’t be used for malicious purposes.
• Use client-side (i.e., JavaScript) form validation. You absolute must also use server-side validation (for security purposes) but using client-side validation gives the user immediate feedback, without having to send the page to the server.
• Use the fieldset and legend tags to distinguish the form from the rest of the page. I really like these tags and also feel they are underused. Multiple fieldset and legend tags can be used to separate a longer form into its logical components. See the example for what these do to a form.
• Place a submit button at the top and button of a long form. I’m not completely sold on this one but thought I’d mention it as Rob Huddleston advocated it in his presentation. The argument for it is that user’s often go back up to a page or may like having it there if they have to correct a couple of quick things. The argument against it is that it may encourage the user to submit the form prematurely (i.e., before they’ve scrolled down and seen the rest of the form).
• Use the label tag for all inputs. This is an accessibility issue, plus using a label brings up some nice features in the Web browers. For example, most browsers will bring focus to a form element if you click on its label. Labels can be written in a couple of ways, but here’s one recommendation:

<label for="something"> Something </label> <input type="text" id="something" name="something" />

An HTML form should not…

• Request information you have no intention of using or needing. Rob Huddleston pointed out, as a common example, that e-commerce sites don’t really need to ask the credit card type, as the number itself indicates the type.
• Use tables. Tables are pretty outdated by now and should be used sparingly, if at all (CSS should be used instead). Besides the aesthetic and standards issues with tables, they break up forms poorly and can interfere with the use of label tags.
• Contain reset buttons. This is one I learned ten years ago that’s really stuck with me. And yet, lots of forms still have reset buttons. The argument against reset buttons is that the user may inadvertently click it instead of submit, thereby destroying all of their efforts. And how often do users actually need to reset a form? Never? Almost never? More likely a user would either reload the page if they want to start from scratch (which I just don’t think they ever need to do) or go to another page if they decide not to submit the form. Really: best not to use reset buttons at all.

Rob Huddleston also recommended the books Don’t Make Me Think by Steve Krug and Designing with Web Standards by Jeffrey Zeldman. I haven’t read either yet myself, although both are on my wish lists. I think it’s safe to say that both are considered standard books on the subjects.

I’ll be posting more on HTML forms in this blog, and you may also want to check out my post on poka-yoke. When I get the chance, I’ll try to add some CSS suggestions for making forms look even nicer.

The thinking behind poka-yoke is that a thing–software, hardware, whatever–shapes the user’s behavior in order to prevent or limit mistakes. An example that Wikipedia gives is how the key in an automatic transmission car cannot be removed unless the car is in park: the car tries to prevent you from leaving it in an unsafe state.

As Hoekman said in his presentation, we should be designing Web sites and software using poka-yoke, but often the design and interface of our creations encourages users to make mistakes. Or practically forces them to. For example, if you want a date in a specific format, you could indicate the format required. But a better solution would be to use a pop-up calendar widget where the user selects a date, that then formats that date properly. Even better, program your system so it accepts a date in multiple different formats in case the user doesn’t use the calendar widget. This last notion is part of a general theory of providing alternatives to your users, not trying to lock them into using your site in one set way (again, this is coming from Hoekman).

For more information on this subject, you should check out Hoekman’s site and his books. I’ve not read them myself, but have added them to my ever-growing list of books that I intend to read someday. His first is Designing the Obvious: A Common Sense Approach to Web Application Design. His most recent is Designing the Moment: Web Interface Design Concepts in Action.

Once you’ve finalized all the functionality and appearance of a site (or thought you have, at least), you should…Confirm that all links work. You can use automated software that will spider through your site and report any dead links. Using one of these applications, and there are free ones available, is really simple and definitely worth your minimal effort.

Validate all HTML. Use an online HTML validation system to confirm that there are no syntactical problems on any page. This should include pages that are the result of form submissions, with and without errors, etc. Any page that a user may see in any state should be validated!

Test! Test! Test! You’ve already tested your site, right? Lots of times? Have your spouse or significant other or parent or roommate or whomever test it. Have someone less technically skilled than you test it. Retest it yourself, this time with the approach of “What happens if I do this?”, even if what you attempt is something you’d never think anyone would ever try.

Test in multiple browsers on multiple platforms. You don’t have to take all of these steps using multiple browsers on multiple platforms, but you should at least hit some of the key pages so you know that everything looks right. Also keep in mind that IE 6 behaves differently than IE 7 or Firefox 2 vs. Firefox 3. Just testing in the latest version of one browser is not sufficient. To simplify things, consider using a site like BrowserShots.org.

Try to hack your site. Make sure you’ve applied good security measures by doing very, very bad things and making sure nothing horrendous happens.

Have a good “Page Not Found” page. Although it’s best not to have dead links on your site, a truly professional site has a nice “Page Not Found” page that handles any missing pages. It should look like the rest of your site, provide a helpful message as to what happened (i.e., why they’re seeing that page), and provide navigation to the site’s actual pages.

Well, that’s the list I have at the top of my head. I’m sure you have other suggestions and I’d love to hear them!

Anyway, as a person that develops Web sites for a living (or part of my living, at least), I’m sometimes terribly annoyed when I find a site that doesn’t work or make sense. As a person that likes to think he knows what he’s doing when it comes to Web sites, if I can’t figure out something, I can’t imagine that the less knowledgeable person could. I think getting UI right is hard for people as it can be difficult imagining how others might use the software or site you’ve developed. I’ll provide more specific recommendations on this subject soon, but I wanted to mention this as a recent area of interest now just so you know what to expect in the next couple of weeks in this blog.

One particular idea I’ll throw out here was presented at one of the Adobe MAX sessions I attended. That speaker talked about how you should be “an ambassador for the end user”, which is a nice phrase and a good reminder. He also pointed out that while you’re developing software or a Web site for a client, they often won’t be the ones interfacing with your creation. So as a Web developer, you need to hit the mark between giving the client what they think they want and giving the end user what they really need.