Unnecessary Regular Expressions

Regular expressions are powerful. They are the jackhammer for all chiseling purposes. In some situations they work great, but often they are either overkill or computationally unreasonable.

Regular expressions introduce a state-machine that is hard to optimize for each case.

Here are a couple regular expressions that I’ve seen within code that was replaced with easier-to-read and faster code.

s.replace(/[^.]*/g, “”).length

This regular expression removes all non-period characters in a string. It then queries for the length of the new string. This effectively just gets the number of periods in the string.

A much simpler approach, and also faster, would be to walk through the string and just count each instance of the period character.

var i, l = s.length, count = 0;
for (i = 0; i < l; i++) {
  if (s[i] == '.')
    count++;
}

s.replace(/\s+$/, “”)

This regular expression removes all whitespace at the end of the string. A much simpler approach would be to use the trim() function. There also exists non-standard functions trimRight() and trimLeft() that can be used to only remove whitespace from a specified side of the string.

Testing it out

If you’d like to see the performance differences for yourself, you can run the character counting and string trimming benchmarks on JSPerf.

Applying Fitts’ Law to Commonly Used Buttons

In a previous post, I covered my work on improving the usability of the Back button in Firefox. Starting with Firefox 8, clicking on the area between the edge of the window and the Back button will fire a Back-navigation event.

The idea behind a change like this comes from Fitts’ Law. From Wikipedia, Fitts’ Law “predicts that the time required to rapidly move to a target area is a function of the distance to the target and the size of the target.”

All operating systems that I have used stop users from moving the mouse off the screen (outside of the virtual desktop space). This means that if a user hurriedly moves their mouse across the screen, it will stop on the pixel that borders the edge. By adding an action to this area, the area becomes a very easy to hit target for users.

Taking advantage of this feature is not unique to Firefox. There are many individual parts of the Windows user interface that exhibit this same usability trick.

1. When a window is maximized, the Close button is positioned in the top-right corner of the desktop. Visually, there is four pixels of padding between the button and the right edge of the screen. However, clicking in the padding will still close the window.
2. The Start button is located in the bottom-left corner of the screen. There is eight pixels of padding between the button and the left edge of the screen. Clicking in this padding will launch the Start menu.
3. Windows 7 introduced a button in the bottom right of the screen that is used to show the desktop. There is no padding between the button and the edge of the screen.

I was not part of the decisions to place these button in these positions, however I strongly believe that Fitts’ Law played a role in their location.

These are just a few of the many ways that Fitts’ Law can be found in user interface design. See if you can find others that I didn’t mention 🙂

Performance Improvements of Screencast.com

The latest Screencast.com release included a couple speed improvements that were quietly included.

URL improvements

The first improvement was one requested by Kyle Mulka, of Twilk, during a visit to TechSmith. Kyle mentioned that he wished the Screencast.com short URLs would stay short after the web page was accessed. He mentioned that a lot of users like to copy and paste the URL from the address bar and use it in tweets.

I spent a bit of time researching what we would have to change to fix this issue, and in a couple of days we had the changes implemented.

This change also brings about a nice speed improvement to the loading of pages on Screencast.com. Previously, when a piece of content was visited, the server would reply with an HTTP Status Code 302 - Found. This causes the browser to then load the page at the redirected location. This little bit of communication takes time, and with our new change we have removed this initial hurdle.

Here is a graphic showing the change in loading times:

With this improvement, we have increased the speed of viewing your Screencast.com content by 4.1% on average. If you are viewing your content from outside of North America, you can expect an even larger speedup.

Reduced page size

The second improvement that was added to Screencast.com was a new library layout. Much care has been taken to reduce the filesize of the webpages, to the point where loading up my library using the Library (beta) only uses 1/4 of the bytes yet sends more data. The Library (beta) also makes 11 less network requests than the current library. This means that your Screencast.com library is now more accessible under tighter network conditions such as 3G.

Static vs. Dynamic Scoping

Have you ever heard of dynamic scoping? Most of us have worked in environments where static scoping is all we have, and probably for good reason.

One of the first things people think about when they hear the words “dynamic scoping” is dynamic memory, which is not at all what dynamic scoping is. Dynamic scoping could also be thought of as context-specific scoping.

C, C++, C#, and JavaScript all use static scoping, whereas Perl and Logo allow dynamic scoping though their local keyword.

Here’s an example to compare the two:

Static scoping	Dynamic scoping
int b = 5; int foo() { int a = b + 5; return a; } int bar() { int b = 2; return foo(); } int main() { foo(); // returns 10 bar(); // returns 10 return 0; }	int b = 5; int foo() { int a = b + 5; return a; } int bar() { int b = 2; return foo(); } int main() { foo(); // returns 10 bar(); // returns 7 return 0; }

Dynamic scoping means that when a symbol is referenced, the compiler/interpreter will walk up the symbol-table stack to find the correct instance of the variable to use. This can be a cool tool to use when writing software, but also a huge source of errors if it is used accidentally.

JavaScript: The Good Parts presentation

Last week I gave a presentation at Michigan State University to a group of students who have a passion for web development. Many of them are experienced with HTML and CSS, but are just getting introduced to JavaScript.

This talk covers some of Douglas Crockford’s “JavaScript: The Good Parts” book.

Douglas has also posted his slidedeck online if you would like some more information. I removed some of his slides from my talk due to its introductory nature.

One of the students in the audience asked for more resources about JavaScript. During the presentation I recommended W3Schools, but after further thinking I realized there are just too many poor recommendations and incorrect statements on W3Schools website. I found a good list of places to grab resources from on w3fools.com:

I wanted to follow up with resource that your members can get more information. This list is from w3fools.com:

• HTML Dog is a fantastic and comprehensive intro for HTML and CSS.
• Opera Web Standards Curriculum covers the basics of web standards-based design in HTML and CSS.
• Google’s HTML, CSS, and Javascript from the Ground Up presents the basics of web development with video tutorials presented by Google’s expert web developers.
• SitePoint is a pretty good reference for HTML, CSS and JavaScript. Their documentation always mentions feature support across different browsers, and describes known browser bugs.
• The W3C, itself, has a wiki-based general Learn page as well as an HTML element reference.
• The MDC (Mozilla’s Doc Center) takes over at intermediate CSS and covers JavaScript better than anyone.