Wednesday, January 16, 2013

Javascript: Developing with State Machines

Usually when I develop a website, I do a lot server side. Servers are fast, PHP5 has some great Object Oriented qualities, and I can send only exactly as much data to the web browser as I need. That said, it isn't always the optimal way of doing things. Web apps rely on often massive amounts of JavaScript executing in the web browser to provide a smooth and seamless "app-like" experience.

For a recent project, my challenge was to display a list of data fetched from a server. Simple enough, but the first version was very procedural, and thus, difficult to maintain. If I wanted to "edit" an item in the list, it meant retrieving from some HTML element the information about the item, and then getting more information from the server, and kicking off a whole new procedure to create a UI of some sort to allow changes to the data. Unfortunately, ECMA Script, at least, out of the box, doesn't have strong Object Oriented support, so while it might be possible to treat each item as an object that seemed messy and relatively complicated.

Instead, I decided to use a State Machine, a decision that I will take a look at here.

JavaScript and State Machines

First of all, JavaScript does have objects, they're just not the kind of objects you may be familiar with. A JS object is very simply a collection of keyed strings. Even a function in a JS object isn't much more than a string labeled as a function. Tell JS to print out myObject.myFunction, and you'll get the code, tell JS to print out myObject.myFunction() with the parenthesis at the end, and instead you'll get the result of executing the function. This simple object representation is very flexible, but very much unlike the rigid OO structure found in OO langages, by virtue of ECMA Script being a prototype language, not an object oriented one.

Luckily, this simple prototype based model is also great for organizing anything, and it makes it ideal to create a state machine.

State Machines

At the most basic level, a state machine is a programming paradigm where a process is repeated, changing what it does based on the previous result. One way to do this, is to use a switch and a loop. Let's look at a stupid and far too simple function for validating an email address by checking that a string has (text)@(text).(text) .

function stateCheckEmail(emailAddress){ var state = 1; for(var i=0; i<emailAddress.length; i++){ switch(state){ case 1: if(emailAddress[i] != '@'){ state++; }else{ state = 0; } break; case 2: if(emailAddress[i] == '@'){ state++; } break; case 3: if(emailAddress[i] != '@'){ state++; }else{ state = 0; } break; case 4: if(emailAddress[i] == '.'){ state++; } break; case 5: if(emailAddress[i] != '.'){ state++; } break; } } if(state == 6) return true; return false; }
    The state machine, however, isn't enough of a paradigm for an entire project without needing to be expanded in some way.
  1. A state machine at its core is simply a way of saying, "I have an easily accessible variable or object that indicates the current state of my application."
  2. A state machine still requires some programming in the terms of functions.
  3. A state machine is a great concept, but it doesn't inherently provide a way to produce code like, say, an MVC paradigm.
In order to expand the paradigm appropriately, therefore, I started by creating my state machine with three objects. I'll use an example of a To Do list.

First, I need to store the machine state. toDoState will be a simple object with key-value pairs, each key representing a part of the machine state. For example, want to know what items are loaded into your state machine? toDoState.items can hold that information. When you click on one to select it, you need to set the state machine so that it knows, and you can do that by setting toDoState.selected. Determining what goes in to the state object is a bit tricky, but I tried to adhere to certain rules.
  • If the information can be used multiple times without needing to change or be reloaded, you can load it once into the machine state.
  • Any item that can be "viewed" or "selected" should also be here.
  • If something needs to be loaded from the server, do it once, and then only update it when needed.
  • If possible, only update the specific part of the state object that has updated.
Next, I want to separate from the state machine reusable code, functions. To do this, I created a second object to work with the first, which I'll call toDoFunctions. I'll also hold to the same pattern convention as the state object. For example, since this is an AJAX powered list of To Do notes, I may need a function to retrieve the list of notes from the server. To reduce server calls, I want to get this into the state machine. Now, things start to come together. 

toDoState.items = toDoFunctions.getItems();

Now, the items are part of the state of the machine. That might sound odd, but it makes more sense when we consider the third part of the extended paradigm.

When creating web pages, eventually, you need to generate HTML code. One of the biggest problems with creating HTML code on the fly, say, using jQuery, is that modifying that generated code is not nearly as easy as editing it if it's just HTML. This brings in to play the last part of the extended paradigm. This third object, I'll call it the "generator" will take care of producing pieces of HTML code. Each object will read the state of the machine and return the appropriate snippet of code based on the machine state. Now, having the list of items as part of the state makes sense, because if we call a function, say, toDoGenerator.itemsHTML(), it should return the HTML for the items that are in the state machine. This means if you delete an item, you just remove it from the toDoState.items object, call the generator function again, and this time you get back the HTML without the removed item, as it always reflects the current state.

Results

Creating a state machine for web apps with this extended paradigm has proved very useful to me. It makes it easy to manipulate the machine at any point, by simply changing the appropriate value in the states object, and allowing the code to execute as normal. It also makes it clear and concise to generate the HTML required for displaying the web app.

Tuesday, January 8, 2013

Impact on the Go - Designing Mobile Websites

Earlier today, catching up on my daily Reddit, I came across an article comparing the different methods of building mobile websites over at Six Revisions. Mobile web development is something that I've been working on ever since I got my first smart phone, the Android powered Motorola Droid 1. The phone was relatively light on resources compared to the monsters we have today, and large websites loaded slowly, and made the phone crawl. When it came time to actually design a mobile website, though, I ran into problems. I thought "this is what CSS is for!", but mobile browsers didn't pick up on the "mobile" tagged style sheets, and so I needed a better solution. One option that was becoming popular at the time was to make some sort of mobile portal, like "m.omniimpact.com". Unfortunately, this is an SEO and content management nightmare. Finally, I settled on a hybrid approach, using a special PHP script that I wrote (you can find the oi_mobilesupport script on Github) to make sure that pages could be presented in a mobile-friendly manner, while not requiring duplication of content. Then, there came the responsive web design revolution.

Responsive web design is a technique using CSS media queries to adapt the CSS on a website based on the width of the viewport. Now, some websites have embraced responsive design to fantastic effect. The Boston Globe is one of the best. The site displays all content in all view modes, fitting neatly to the size of the browser window. Resize even your desktop browser and watch the website adapt.
Responsive design at its best, the
Boston Globe even supports
the equivalent of tablet screens.


Unfortunately, the Boston Globe is somewhat unique in how well the technique actually works. Being a newspaper, the website is naturally text heavy. They can squeeze by with just one dominant image on the home page, and the rest being mobile-friendly sizes even on desktops. Although it is possible to make other types of websites scale, I often found responsive websites to exhibit the same problem I was trying to avoid in the first place; slow load times and poor performance.

A refresh of the original design by another company,
the updated website by Omni Impact now presents
equivalent content instead of a limited mobile website.
The article from Six Revisions takes on the question of mobile web development techniques with great examples, clear pros and cons of each technique, and doing some actual timing of websites that use each of them. The convenience of non-duplicated data, the benefits to SEO, and significantly improved load times were all reasons that I always liked the hybrid approach and implement it in the websites that I create. I was pleased to see that same approach receive some oft-forgotten love from Six Revisions.

To give you a quick summary, the three major methods of creating mobile websites are dedicated mobile sites, responsive design, or a hybrid method, which often utilizes server-side browser detection. Dedicated mobile websites require a copy of the original data, can cause problems for search engine optimization if used incorrectly, often have difficulty redirecting users to the appropriate content on the other site, but they load quickly and can have highly tailored user interfaces. Responsive websites are often slow to load, difficult to make properly, and you are limited by what you can do with CSS, for example, adding or removing elements can be done, but requires all the elements to be loaded anyway, increasing load times. Responsive design also offers no option for the user to choose their preferred website experience. Hybrid design delivers a mobile-optimized version of the websites code, but utilizing browser detection instead of a different URL. When done properly, hybrid mobile website design provides the quick loading of a dedicated mobile site, without the data duplication or SEO nightmares. A good example of how hybrid design can take advantage of server side processing is presenting an alternate footer, as shown in the above screen shot. Note that on the mobile version, a fixed footer provides quick access links ( tel: and mailto: ) that will open the appropriate app on the user's phone. This code is used only when in mobile mode. On the other hand, the additional images used in the header are blocked on the mobile version, rendering the header with only text to speed load time.

To get the details, check out the full article article at Six Revisions.



Seven Years Ago; The Beginning of Omni Impact

Seven years ago, a student was putting away his materials after Spanish class. It was the last period of the day, and this student would prefer to take his time wrapping up and chatting with one of his favorite teachers instead of braving the masses of younger students in the overcrowded school. As the last of the materials from class went into the backpack, the frustrated typing of the teacher became apparent. A glance behind the student explained the cause; the teacher was trying to edit a website in one of the clumsiest systems he'd seen. "SeƱora? What kind of website is that?" he asked.

"It's for a non-profit organization I'm on the board of." was the reply, followed by "I'm sorry, though, I can't talk now, we need to update this page, and the software to do it is just awful."

The student thought for a moment. "I might be able to help you."

 This was the start of Omni Impact. I'm Daniel marcus, and seven years ago, I began work on my first major web development project. What began as a way to cut costs for a non-profit organization grew over the years into a full fledged content management system. Each year, hundreds of teachers log in to a platform that allows them to share files between each other, and stay in touch. Each year, I have improved my skills and widened my portfolio. Now, I look forward to sharing some of that experience with you through this blog.