Speeding Up Your App with Request Caching

Recently in my Mainstay Monday posts I’ve talked about creating linked lists and queues in Javascript. Each of those topics is so dense that just writing about the basics of creating and using them took full blog posts. Really all of that was the lead up to today’s post.

I’ve worked in a couple of different, large single page applications and in every one I have, ultimately, encountered a need to cache requested data and respond to multiple functions needing that data before the original request is complete. No promise framework or other specialized library ever fit the need because, really, the call should only ever be made once.

I’ve had team members solve this problem in a naive way and simply make the call over and over again. What happens, though, if the data you’re requesting is large and takes a long time to retrieve? This means you have now introduced multiple seconds of latency into your app. I think we can all agree that waiting for 5-20 seconds for data to come back is about the worst thing you can do to a user. They get frustrated and confused. They think the app has stalled or their browser has crashed.

Problem #1: I need to store the data when I get it.

This is easy. If you just need to store the data and retrieve it upon request, you can create a hashmap with keys and values. Now, when a request comes in, first your data service will look in the hashmap and see if the data already exists. If not, you go fetch it, bring it back and then, upon return, you hand the data back into your app.

This is the most basic kind of cache and it will suffice for calls that are made infrequently. Initial data for your app to bootstrap can be handled this way. Typically a single request will be made and you can just go fetch it, then cache it. If the app wants to rebootstrap for some reason, the data is in memory and you can skip the wire call.

The more challenging issue is this: what if you have data that is requested often?

Problem #2: I need cached data to only be requested once, but the program asks for it everywhere.

This is where it gets really interesting. It’s quite common for a program to need to refer back to permissions and user capabilities often. ACL tables can get quite large and it is preferable to only request these once. The problem is, the program will need access, possibly multiple times, for even a single page. This means your application will request the same data multiple times before the service you’re accessing can return.

I’ve seen a page make 100+ requests at the same time to get data from a service. It’s not pretty.

Fortunately, queues provide the solution for this. We can queue all of the callbacks that our application generates and resolve them at once when we get the data back. This means we could, in theory, request the data on app bootstrap and never request it again. Worst case scenario is we request it just in time and the user has to wait once.

This is where the real meat of the problem is. We need to construct a queue backed request system with a cache layer to manage our data. This all sounds a bit scary but, once we break it down, it’s all just bite-sized pieces we can easily manage. We have even already decided on the data cache structure.

Before we start down this road, I would like to point out, a friend of mine introduced me to a rule I use all the time. It makes testing easier and it makes coding easier.

Never create and use an object in the same place.

The easiest way to answer this rule, for our current problem is with the factory pattern. Our factories are going to be relatively uninteresting, but because it creates good seams to work with in our code, and it does a nice job of separating our concerns so we can reasonable, correct abstractions.

So, since we know our mechanism is going to be queue-backed, we need a linked list. I went ahead and created a linked list item factory as a gist. It creates generic linked list items, so you could really use it for anything. We’re going to use it to construct our queue. Here’s our first factory, linked list items:

Once we have our linked list item factory set to go, we are ready to construct our queue. Once again, we are going to want to work with a factory. Our queue logic comes straight out of the queues post, it’s just wrapped up in a factory so we can easily separate it and work with it alone. Here’s our queue:

Now is where we start breaking new ground. Our cache, and its factory, are going to handle a few things. Consider this a little like learning to juggle. We have to get things in the right order, and it’s all interconnected, so you might want to read the code a couple times. Let’s have a look at the cache factory and then we can talk about it.

The short and sweet version of this is, we receive a local request for data, if it is in the cache, we resolve the request and move on. If we don’t have the data, we queue the callback with any other outstanding callbacks and wait for our service to return the data we need. In order to ensure we don’t have overlapping concerns, we rely on a cache instance per unique data request. Basically, this means if you make a request with { id: 1 }, it should always go through the { id: 1 } cache. This way if your application needs to come back later and request data using a different id, it can without colliding with the original data cache.

To expand this idea, let’s take a look at the steps that happen.

First, we have a cache factory. The factory takes in a request function, which it assumes only needs a callback to be complete. With this function, it news up an instance of the cache object. By using a factory, we can guarantee instantiation correctly, every time. Here’s what it would look like in code:

I’m assuming permissionService is already created and get is a method to perform a standard HTTP GET. Honestly, this could be anything, just as long as all of the correct parameters are bound.

It’s important to note that no request has been made yet. All we have done is create a cache we can make requests against. Our app is still sitting there patiently awaiting instructions for what to do. This entire setup process takes microseconds to complete and you now have everything you need to manage bursts of traffic gracefully.

Once we have our cache ready to go, we can make a whole bunch of calls and it will only make a single call across the wire. This gives us a major performance boost, which allowing our app to carry on blissfully unaware that anything has changed. Here’s what it looks like:

The first request, regardless of which it is, will cause our service to create the cache. Each subsequent call will just end up the queue. Once the request comes back from our remote service, all callbacks will be resolved in the order they were received. Even better, if something else is kicked off in the meanwhile, this will simply be added to the queue and all is set and ready to go.

Adding this kind of data management to an application adds some complexity, so it may not be worthwhile to manage all data requests this way, however, when a particular behavior starts making lots of requests across the wire, this is a great way to throttle the requests back and improve efficiency in your app. The best part, as long as you are working modularly, is that you will only need to introduce changes in one place. This means the bulk of your application will remain precisely the way it is today while repairing a bottleneck that can slow your app down and frustrate users. So, get to profiling your apps and cache some data.

Comments Off on Speeding Up Your App with Request Caching

Yo dawg, I heard you like accessibility…

So I put accessibility in your menus so your users can use your site even if they are disabled.

Okay, so I suck at yo, dawg jokes. I did, however make a handy little menu script.  It’s small. It’s functional. It supports accessibility features like roles and keyboard access. It’s easy to turn some plain old HTML into a menu without having to know ANY javascript.  Am I a mad genius? Quite possibly, but I’ll take what I can get.

So, here’s the deal, you can download the alpha release at the following link:

https://github.com/cmstead/ClickBeetleJS/releases/tag/v0.5-alpha

If you want to actually code and help make it better you can fork the project here:

https://github.com/cmstead/ClickBeetleJS

Important things you should know:

ClickBeetleJS requires jQuery.
Pull requests won’t be accepted without passing tests associated.
All my tests are written with QUnit. Please write yours using the same framework.

I hope this is useful for you.

Help me make the web a better place.

Comments Off on Yo dawg, I heard you like accessibility…
Similar posts in Coding, Javascript, User Experience

We Live in a Biosphere

You may or may not be aware of this, but when we are interacting with an application, we are entering a biosphere. People always talk about suites of applications as being an ecosystem, but even within the constraints of single app, we are still interacting with a smaller, but equally important, ecosystem.

About three years ago, I wrote a blog about page-behavior taxonomy or, as I generally refer to it now, behavior taxonomy. This taxonomy is really a mental model the user creates based on previous interactions they have had within your page, site or application.  It’s really crucial to understand that as you present links, behaviors and interactions, you are training your user.  When you break that interaction model, you are breaking rules the user expecting you to follow.

Consider the biosphere projects scientists construct for the purpose of experimentation.  Everything in that tiny ecosystem must work together properly.  If an element is introduced which changes the ecosystem, it could cause a breakdown of the entire experiment. These small changes are what happens when the biological equivalent of microinteractions are not considered.

The key to considering these mental models is to look at the application as a whole and start developing an expectation of what the user will experience throughout their time in your app or site. If you look at the app as a whole early on, then it becomes clear what each interaction should bring.  Think about how people are going to move about.  What kinds of input are they going to give.  Why are they doing it and how would they expect it to work?

Of course you should expect change, but the if the initial behavior taxonomy is sound, new additions will only serve to enhance the experience.  If, on the other hand, care is not taken to develop the rules to which your app should adhere, you will paint yourself into a corner.  You will make decisions early on which will force your hand later on.  If you choose to break from the model, you will also break your users trust If your app is something that is going to be foisted upon users, they will learn to deal with it and resent you.  If your app is something users interact with by choice, they will leave.

In the end, we are all in this little biosphere together.  Let’s live in peace and harmony.  Consider the environment and care for it. Your users will thank you for it. Consider your app’s behavior taxonomy and make the web a better place.

Comments Off on We Live in a Biosphere

Monetizing the Web

Today I read an article about Irish newspapers plotting to charge for linking to their content. We’ve all heard about this before and people seem to get up in arms about it every single time it is mentioned. I think this frustration and disgust are misplaced.

See, here’s the deal: if you want to make money from people using your site, you have to get them there.

Ultimately, there is a paradigm shift that happened with the web which traditional media is having a hard time wrapping their brains around — links are gold. They are the currency of the web and the word of mouth in the electronic universe.

At one time, it made sense for media outlets to limit the distribution of their content through other media channels. It hurt sales and trimmed valuable advertising money from their pockets. They never said “don’t mention our article to people or we’ll charge you.” That’s foolishness. Big media wanted, and still wants, people to know they got the scoop before anyone else. It keeps them in business.

So why limit linking? It limits the number of page views and, subsequently, the amount of advertiser money that comes in.

I get it. They want you to click around the site looking for that one piece of content you heard about. The problem? News sites pretty much universally stink with regard to user experience and findability. If it isn’t on the front page it may as well have never happened. This is the heart of their problem, really. They are spending so much time trying to milk every penny out of someone’s pocket they can’t see they need some real help.

My message you to, media outlets: Fix your sites. Make them easier to use. Put your reader first instead of your pocketbook. The advertising money will come. If you want to erect paywalls, fine, but don’t kill the one thing which might save you. Protect your links. Treat them like someone handed you free money. Encourage people to share. If you don’t, I won’t be angry, I’ll just never know you existed. Do us all a favor and make the web a better place.

Comments Off on Monetizing the Web

Plan Your Device Strategy

As mobile gains ever more ground and mobile first continues to be knocked around as the design strategy for the web, I encourage people to look at their use statistics.  Although mobile first is a great strategy if you don’t have statistics to draw upon for your site, or your reorganization needs a mobile injection, nothing will serve you better than the statistics regarding what your user does on your site.

Instead of simply adopting an oversimplified “mobile first” strategy, I decided it would be best to figure out what the user is doing in each mobile context.  For the simple sake of reason, I generally say we have three platforms and four positions to deal with.  Either your user is on a small-profile device like a phone or palm-top computing device, they are on a tablet, or they are on a standard computing device.

This gives us something really easy to work with.  There are three devices, two of which have two orientations.  It might seem like this translates to 5 total designs to commit to.  Fortunately, the phone in landscape is just about the same width as the tablet in portrait.  We are left with four design contexts to worry about.  Realistically, though, we can start with just three pieces of the puzzle and extrapolate the intermediate fourth.

My latest project, for which I am leading a team, needs two key items to make sense of the high-priority items on the site: device used and pages accessed.  After a bit of careful fiddling, I uncovered the following chart:

Device to Traffic Chart

Device to Traffic Chart

This chart helped me to figure out what our device strategy would be.  Clearly our visitors from mobile devices have much more limited interests than those visiting from a standard computer interface.  Mobile first means we should guess at what should go on a site and what the user will want to do on a smaller device.  By analyzing the data, we can clearly define interactions on mobile devices which may, actually, not be important to highlight on the desktop.

Instead of working with mobile as a pared down version of a complete site, we should aim to understand what a user wants to accomplish in a different context.  This is not a cut and dried rule of thumb but something we can produce through a little bit of careful reflection on what users are doing right now.

For your next project, instead of taking a mobile-first design stance, review your user data and serve users in each platform according to their needs.  Provide clear signposts for your users.  Develop a device strategy and make the web a better place.

Comments Off on Plan Your Device Strategy

Herding Cats or Looking at Curated Search

You know what makes Google awesome? Their search algorithm is pretty darn smart. You know what makes DOMZ awesome? Every stinking link on there has been verified by a real, honest-to-goodness human being. You know what sucks about site search on most websites, even when they’re running a Google custom search? The only time a human ever looks at the search is when they are actually using it to find something.

This is where a curated site search comes in.

When I say curated, I mean it in much the same way a museum curator takes care of the displays, carefully selecting the pieces to display and updating things as new events and collections are integrated or moved out of public display. Think about it, if you went to a site looking for glasses for your cat and did a search saying “Siamese cat glasses,” wouldn’t it be awesome if, right above all the standard mediocre search results, you got a little bit of content saying “we’ve got glasses that will look great on your Siamese cat?”

Of course it would.

The benefit of this is that you have a better understanding of what a person is looking for than a computer ever will. Why? Two reasons, really. First is because you are a person and, I suspect, you have done searches for things before. Second, no matter how good the crawler is that indexes your site, you have access to your analytics, which means you know what people are searching for. (You’re running analytics, right?)

An example of how this works can be found on the HP site. Below is a screencap of what their search looks like if you search for TouchSmart. (I picked that term because it is their current ad and I knew I would get something good. Color me sneaky.) You’ll note they have a list of search results on the screen, but the very first thing to come up is a link straight to the TouchSmart product information.

HP Curated Search Content

Pretty sweet, right?

Okay, maybe looking at a computer search page doesn’t get you all revved up and ready for action, but imagine if that image were your Siamese cat in need of glasses. Now we’re talking turkey, right?

That cat needs some glasses

This doesn’t do anyone any good if it doesn’t do anyone any good, right?

Absolutely.

What?

The long and short of it all is, by curating content for commonly searched items on your site, you make the information/product/widget/catglasses more findable. This means you are more likely to have conversions from site visitor to customer. Benefit to your customer: ease of use. Benefit to you: more business. Stick that in your ROI pipe and smoke it, Mr. Executive.

In the end, everyone wins when things are easier to find. Since so many users are search-centric, you can serve them well by anticipating the searches they are going to perform and give them the info you know they want up front. This front-loading of work helps to provide a clear signpost for users to do what they were at your site to do: make with the business with you. In short, if you are running a site search for your users you should consider curated content to provide for common searches and make the web a better place.

Comments Off on Herding Cats or Looking at Curated Search

Moving Pieces: Organizing for a Website Overhaul

I’ve read several different books and articles about web projects and how to make sense of what needs to happen when. Everyone has their own slant and it flavors how the entire process should go. Meanwhile they hope the “magic” in another group is happening.

It’s really important to have a list of the things you need to accomplish. I am not going to tell you who does what. That depends on your team and how you dole things out. I will tell you that each of these pieces needs to be addressed or you’ll have a tough time moving to the next step.

Without anyere’s my core list of stuff to check off:

  1. Analysis
    • Business and user needs
    • Content Inventory and analysis
    • Site analytics (Look at search terms. This is your user talking TO YOU)
    • Personas
    • Brand, voice and message
  2. Collect moving pieces
    • Curated existing content (text, images, documents, etc.)
    • New content (Get it early or you’ll hate yourself later)
    • Process functions (search, dynamic functions for displaying content, etc.)
  3. Design and prepare
    • Information Architecture (Hierarchy, page layout, workflow, wireframes, etc.)
    • Build structured documents containing all raw copy for the site
    • Colors, designs, images, flow, implemented voice and message
    • Get info about servers, technical needs, etc.
    • Prepare SEO deployment plan
  4. Build
    • Prepare comps using design specs and wireframes
    • Build templates to house content based on wireframes
    • Implement design via styles as comps are completed
    • Edit content to match voice and message and begin inserting into CMS
    • Prepare SEO: descriptions, titles, friendly URLs, etc.
    • Prepare 301 redirects for old pages being replaced or moved (I feel this SEO technique is important enough it needs to be stated separately)
    • Ensure servers are online, technical needs are met and everything is ready for launch
  5. Launch
    • Stage site out of the public eye and QA completely
    • Deploy site (Post-QA)
    • QA for sanity (All pieces are behaving like they were on staging, nothing is broken)
    • Celebrate!
  6. Postmortem
    • Review analytics and compare to pre-release stats
    • Inventory new site (include all new copy, new images, etc.)
    • Review conversions

Build your core list of needs and lead your team to the promised land. One project at a time, make the web a better place.

Comments Off on Moving Pieces: Organizing for a Website Overhaul

Project Kickoff: Prepare to Deliver the Goods

We’ve all been there at some point or another. A new project is just about to start. Everyone in the know is bracing for impact and the people who are going to contribute are blissfully unaware of the monster lurking around the corner.

Generally the kickoff goes like this:

“Hey, everyone, our client needs an update to their website. You know what you need to do, so let’s hit it. Peace out.”

Do they know what they need to do? At a high level, maybe? Probably not, really.

Stakeholders don’t know what’s coming. The client doesn’t know what they need. The design and development units are waiting until the other one is done with “their part.” In the end, everyone scrambles at the 11th hour and the project comes together. Barely.

Let’s hit rewind and do this kickoff the right way. If you are a team lead, figure out what you need. Sort out who your users are and what business needs are being addressed on your site. Contact stakeholders early, share what you need and the listen to what they want. Use this to sort out your priorities. Organize the moving parts, call your team together and give them the rundown.

Once people have their marching orders, collect everyone for happy hour. This is the first step in a long journey, start it with a cheers instead of a fizzle. Kick off your projects right and make the web a better place.

Comments Off on Project Kickoff: Prepare to Deliver the Goods

Information Organization for Seeking Behavior in 5 Steps

Information comes in all shapes and sizes. Some is simple. It’s copy that goes on a page. It’s an image. It’s a sound file. It’s a single PDF. It’s whatever atomic piece of information you can imagine. Then there is the molecular level, for instance, whole web pages with mixed content. Then there is listed information: movie titles, collections of documents, retail products, animals with feathers, types of beer, whatever.

Listed information can get tricky.
Continue reading “Information Organization for Seeking Behavior in 5 Steps” »

Comments Off on Information Organization for Seeking Behavior in 5 Steps

UX: The Break Room Microwave

As is typical with the break room at many offices, we have a microwave. Actually, we have two, but there is one in particular that everyone knows about and avoids. Everyone but me*, that is. It is a machine crafted in the forges of bad usability and total misunderstanding of user journey.

The main requirement for a microwave is that one be able to set the time for which their food will receive a nuclear blast, converting last night’s roast beef into magma. Either there is a “time cook” button, or you simply enter the time directly. The uranium-235 does the rest. Continue reading “UX: The Break Room Microwave” »

Comments Off on UX: The Break Room Microwave