Cyber In Securities curated by Lisa Moren, visual arts, and presented by the Washington Project for the Arts, received a positive review from the Washington Post, labeling it as a display that “should be one of the fall’s most discussed local exhibitions.”

Read the article at the Washington Post’s website: “Fall gallery shows: ‘Cyber In Securities,’ ‘Silver Clouds,’ ‘This is Labor’”

The exhibition features work by 13 artists or teams, “who contemplate the role of information-gathering, including surveillance by intelligence and law enforcement agencies. . . All use technology to comment on technology and its implications.” 

Cyber In Securities is on view through Sept. 27 at Pepco Edison Place Gallery. Learn more about the exhibition here.

Image: Hasan Elahi, Hawkeye, 2012

I recently spent a week at Hilton Head Health, a weight loss spa in South Carolina. Part of the experience was classroom learning about lots of different health related topics. While hearing all about those things, I couldn't help but think about parallels between personal health and the health of websites. Mostly about web performance. Perhaps looking at these similarities is useful, as there is great value in taking care of both and sometimes a good ol' analogy can trigger understanding and action.

Losing weight is both very simple and very difficult

The one true way to lose weight is to burn more calories than you eat. This is very simple in concept. Yet, as most of us know, extremely difficult. There is also one true way to make websites load quickly, don't put so much stuff on them that it makes them slow. That is a very simple concept but not so easy in practice.

Throughout the day we are exposed to far more unhealthy eating choices as we are healthy eating choices. The unhealthy choices are typically easier, faster, and cheaper.

You might face challenges like this in the organization around your website as well. Meetings where everyone has an opinion on what needs to go on the homepage. Business needs dictating what needs to go where. Analytics telling you giant images of woman wearing headsets convert better than text alone. While you might win a battle here and there, it is easy to lose ground in the war when it comes to "doing less" on a website.

When losing weight, you might go on a diet. Literally a plan for what you can eat and how much. This guides your choices. The web equivalent might be a performance budget. Perhaps something as simple as: on any given page you get X requests for X total size. Let that concept have power in the meetings about what goes where on the site.

Exercise helps you lose weight too, right? It does, a little. But it's not nearly as important as what you eat. As was told to us: "You can't compete with what you eat." The parallel to exercise here might be things like server upgrades.

We need our website to be faster, so can't we just upgrade our servers? Can't our database guy just upgrade something? Those kind of things can help a little bit, but you "can't compete" with what you serve. 80% of web performance is front-end related, which has much more to do with your users computers and internet connections that it does with your servers.

Mindless Eating / Mindless Creation

Part of what makes eating healthy difficult is that many of us don't put much thought into it. We just do it. We don't have much of a plan for it and we don't even think about it as we are eating. Not to mention we are heavily influenced by the circumstances. This book is recommended reading on the subject.

I suspect that most people who work on websites don't pay too much mind to performance, either. They know that they shouldn't use 2MB JPGs, but otherwise don't really think about it. It makes some sense. Many web workers only have beginner level skills. You can't overwhelm a beginner with too much information and it's more important they know how HTML and CSS work than how HTTP requests work. Perhaps it's unfortunate that beginners produce live websites, but I don't think so. That's part of the beauty of the web.

Mindless creation is the parallel to mindless eating here. Just not thinking about what we are building, we're just doing it. We're just getting the job done. Users aren't writing into support about the website being slow so there aren't any tickets to address about it so nothing gets done about it. But of course something does need to be done about it. Performance is just one of those things you just know you have to do because it's good for everything: engagement, conversion, general community karma...

Perhaps you don't want performance details to bog down an efficient workflow - or saddle overworked employees with a new set of concerns. That's understandable, but there needs to be some kind of checks and balances for performance. Some kind of way for the organization to be mindful about performance.

Quantity & Frequency

Bob Wright at HHH has a story about hot dogs. He loves baseball and goes to at least a few games a year. Baseball games and hot dogs go hand in hand. It's no mystery that hot dogs are not healthy, but Bob, typically a healthy eater, always gets one at the game. Is that a terribly disastrous choice for Bob? Nah. A couple of hot dogs isn't going to make much of a difference in a healthy life. It's not the hot dog, it's the quantity and frequency of hot dogs. If you ate three hot dogs a day every day, that's what is going to kill you.

Just like it's not the hot dog, it's not any individual resource on a website that is going to kill performance. It's not jQuery, it's loading 400k of JavaScript over 18 files. It's not a 200k JPG, it's a slider with 25 200k JPG's.

Minutia Bullhonkey

You're not making that double cheeseburger in a teflon pan, are you?! Teflon is so bad for you!!

This is a case of missing the forest for the trees. There is some evidence Teflon may be bad, but it's not super conclusive, hard to do (needs to get to 650°F), and probably not that big of a deal. The double cheeseburger however, is definitely terrible for you.

This is like arguing about loading a JavaScript library when you haven't optimized your images or sprited the ones together that can be.

This is like arguing that === is faster than == or ++i is faster than i++ while you aren't serving the JavaScript as gzipped.

While you could be technically correct that that little change would be faster, spending the time researching, debating, and making those changes could be spent on easier changes that could increase performance by amounts of time orders of magnitude higher.

Sometimes these little performance tweaks are called micro optimizations which I feel is a good name for them. Best suited, perhaps, for creators of libraries, frameworks, and people who work on computationally intensive sites.

There is a huge amount of bullhonkey in food packaging and advertising as well. Did you know that Trix are healthy now?

Fortunately the web industry is fairly honest in comparison. I don't see web hosting companies advertising how much faster they are than each other all that often, a claim they almost certainly couldn't keep as it's too dependent on what you do with that hosting.

Big and Getting Bigger

Perhaps you've seen this map charting the percentage of the population in the U.S. from 1985-2008 (just 23 years).

It goes from most U.S. states having less than 10% of people being obese to most states having over 25% and some over 30%. Pretty staggering growth! It continues as well, four years later in 2012 nation-wide they are saying over 1/3 (35.7%) of all U.S. adults are obese. It's on track to reach 44% by 2030.

Here's some more rather shocking numbers:

• Annual medical costs are $1,429 higher for obese adults.
• More than two-thirds (68.8 percent) of adults are considered to be overweight or obese.
• 77% of adults eat less than 5 servings of fruits and vegetables a day.
• Globally, there are more than 1 billion overweight adults.

I bet you can see where this is going.

Websites are getting bigger and bigger too. That may be no surprise itself, but you may be surprised that the rate of growth is far higher than even these weight-related numbers. Tammy Everts has a great run-down of how this has been going.

Numbers from the HTTP Archive show that from November 2010 to May 2013, the average total website size nearly doubled. And during that time, the rate of growth more than doubled. If that trend continues, the current average website size of 1.34MB will be more like 2.68MB in a year.

To be fair, despite that growth, there is evidence that web page loading times have actually gotten better. This is from Google which collects the data and also provides very fast and very slow internet options, so take that as you will. Also note the metric here was "page load time" in which optimizations to the browser itself play a big role. There is a hard limit to that though, as the browser ultimately needs the resources to do anything.

Internet speed is clearly a major factor here. If internet speed doubles along with the doubling of website girth, we'd probably be OK, but light research suggests year over year growth of closer to 50%.

And that is just averages. Decisions can't be all based off averages. A 2.68MB website is simply unacceptable to a lot of users with slow internet speeds or that pay by the kilobyte. Faster loading websites will always be important and smaller total size will always help that.

Some Things Are Just Bad, Period.

One small public health victory is trans fats. Everybody knows what they are and everybody knows they are bad. Even companies that basically make junk food have taken steps to remove them from the food they produce. Trans fats are just bad, period. You should eat zero of them.

There are some performance related things that are also just bad, period. Not gzipping HTML and text resources is just bad. Not optimizing images is just bad. Not concatenating resources when you can is just bad. Not utilizing simple caching solutions, both front end and back, is bad.

Unwise || Better || Best

Even trained dietitians have a hard time gauging the nutrition of food at restaurants. It's just too hard to know by just looking at the menu (or even the prepared dish). How are us regular folks supposed to make smart decisions at restaurants? You may not be able to guess the calories, saturated fats, and sodium content of one particular dish, but you could probably guess correctly which of two dishes is more healthy. Is a grilled chicken salad better than a steak sandwich? Yep.

In that scenario, the steak sandwich is an unwise choice. If you saw a grilled chicken sandwich on the menu, that might be a better choice. The grilled chicken salad might be the best choice. Fairly obvious, but thinking of it that way can help you make decisions.

While doing day-to-day tasks on the web, we might be able to apply that same thinking. Say you need to add a new illustration to a page on your site. It is provided to you as a 2MB JPG. That would be unwise to just plop on the page. Can you resize it down? Can you optimize it? Those would be wise choices. Does it look like it could be an SVG? Is it a flat color? Could it be integrated into a @font-face font you are already using? Could you use a responsive images solution? Those would be the best solutions, if possible.

You don't always have to make the best decisions. We all know it's too hard to live a perfect life. But if you can lean toward making better decisions by just making simple comparisons and edging toward the wise, you'll be better off.

Are there more connections?

I bet ya'll can come up with more fun personal health - website health connections. What would represent bad cholesterol and good cholesterol? Is there an equivalent to a fad diet?

Also just for fun, I recently re-created the Nutrition Facts label in HTML and CSS. Then I forked that and made a tongue-in-cheek Performance Facts version:

See the Pen Performance Facts by Chris Coyier (@chriscoyier) on CodePen

Just for fun of course, but perhaps this kind of thing can get you thinking about web performance for your site and getting started with a performance budget.

The Parallels Between Personal Health and Website Health is a post from CSS-Tricks

The online IMDb website is a crucial resource for any type of digital video media. Online web series, TV shows, and movies are all cataloged with credits to the cast and studio help. IMDb is probably the oldest resource for learning about your favorite shows or movies.

In the spirit of building on top of web applications I went to the site looking for an API section. Unfortunately it doesn’t appear that IMDb has an official API – but we do have My Movie API. This is a RESTful web service which pulls data from IMDb based on a unique ID or title. You have access to a number of popular datasets along with various return formats including JSON and XML.

For this tutorial I want to demonstrate how we can build on top of this API to create a small IMDb webapp. You can do so many different things with this program, but I put together a simple example which can provide a template for other web developers. Check out my live demo to get an idea of what we are creating.

Live Demo – Download Source Code

Getting Started

First I have put together a small HTML5 document which contains a link to the most recent copy of jQuery. You can include a copy directly from the Google CDN or download a local script instead. Also I’ve created a stylesheet named styles.css to hold the page formatting.

<!doctype html>
    <html lang="en-US">
    <head>
      <meta charset="utf-8">
      <meta http-equiv="Content-Type" content="text/html">
      <title>IMDB API Webapp - Treehouse Demo</title>
      <meta name="author" content="Jake Rocheleau">
      <link rel="shortcut icon" href="http://d15dxvojnvxp1x.cloudfront.net/assets/favicon.ico"&gt;
      <link rel="icon" href="http://d15dxvojnvxp1x.cloudfront.net/assets/favicon.ico"&gt;
      <link rel="stylesheet" type="text/css" media="all" href="styles.css">
      <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script&gt;
    </head>
    

Now the webapp itself just contains a few links which also hold IDs from the IMDb website. Once a user clicks on a link we need to query the My Movie API to find out which TV show they clicked. Then we can display more information into the body of the page by parsing over the JSON response.

  <div id="w">
        <h1>IMDB Mini-Webapp</h1>
        <!-- logo icon http://arrioch.deviantart.com/art/Blawb-PSD-245341011 -->
        
        <p class="desc">Select a TV show to display some related information.</p>
        
        <nav id="tvnav">
          <ul class="clearfix">
            <li><a href="#" id="tt0367279">Arrested Development</a></li>
            <li><a href="#" id="tt0386676">The Office</a></li>
            <li><a href="#" id="tt0121955">South Park</a></li>
            <li><a href="#" id="tt0098904">Seinfeld</a></li>
            <li><a href="#" id="tt1826940">New Girl</a></li>
          </ul>
        </nav>
        
        <div id="imdbcontents" class="clearfix"></div>
      </div>
    

The inner div at the bottom using the ID #imdbcontents will contain the dynamic content. All of the new HTML will be contained inside jQuery variables which then gets appended into the document using .html().

Defining Page Styles

Overall there isn’t a whole lot of detailed stuff to understand from the CSS. I am using a tiled repeating background from Subtle Patterns which adds a nice touch onto the page. Notably the TV navigation section and the dynamic content will require the most styling. But a majority of the stylesheet pertains to custom resets along with the inclusion of a custom web font titled The Girl Next Door.

#tvnav {
      display: block;
      margin-bottom: 25px;
    }
    
    #tvnav ul { list-style: none; }
    #tvnav ul li { margin-right: 4px; display: block; float: left; }
    
    #tvnav ul li a { 
      padding: 3px 6px;
      color: #5e83c6;
      -webkit-border-radius: 3px;
      -moz-border-radius: 3px;
      border-radius: 3px;
      font-size: 1.2em;
      font-weight: bold;
      text-decoration: none;
      background: #dbe4f3;
    }
    #tvnav ul li a:hover {
      background: #cbd8f0;
      color: #526890;
    }
    
    #imdbcontents { display: block; width: 100%; }
    
    .floatright {
      display: block;
      float: right;
      margin-left: 10px;
      margin-bottom: 5px;
    }
    

All of the navigation links are given rounded borders and background colors to appear more like buttons than regular links. Also the internal content is formatted into a div which starts out completely empty. This means it has an auto-adjusted width that we have to fix using width: 100%;

/* clearfix */
    .clearfix:after { content: "."; display: block; clear: both; visibility: hidden; line-height: 0; height: 0; }
    .clearfix { display: inline-block; }
     
    html[xmlns] .clearfix { display: block; }
    * html .clearfix { height: 1%; }
    

I’ve also applied a small clearfix onto the container of imdbcontents. Using the .floatright class makes positioning the poster artwork so much easier. Clearfix helps to make sure the div will fill out a complete 100% height even if the content itself is shorter than the image. The idea is somewhat dated but still works perfectly. If you want to learn more about clearfix CSS try reading this article to get a better understanding.

jQuery API Access

Now we can dig into the more detailed code for pulling out data from the API and then appending it into HTML. At the bottom of my index file I have opened a new script tag just before the closing </body> tag. We are listening for a click event handler on any of the tv show links which will trigger our API codes.

$(function(){
      
      $('#tvnav ul li a').on('click', function(e){
        e.preventDefault();
        var imdbid  = $(this).attr('id');
        var resturl = "http://mymovieapi.com/?type=json&id="+imdbid+"&release=full&plot=full";
        
        $('#imdbcontents').html('<center><img src="images/loading.gif" alt="loading..."></center>');
    

All of this code is executed before the Ajax API call. Whenever a user clicks one of these links we first need to call e.preventDefault() against the click event. This way we do not get the hash symbol(#) appended onto the document URL which can also cause the page to jump. You’ll notice from the variable resturl that defining our endpoint is fairly straightforward.

There is a full list on the My Movie API site of alternative parameters you may pass into the request URL. These options are somewhat different depending if you are requesting an IMDb title or ID. Also the final line of code here will append a small loading gif image into the contents container while we await the JSON response.

    $.ajax({
          url: resturl,
          dataType: 'json',
          success: function(data){
            var title  = data.title;
            var genre  = data.genres[0];
            var poster = data.poster.imdb;
            var url    = data.imdb_url;
            var plot   = data.plot;
            var rlseyr = data.year;
            
            var cdiv = $('#imdbcontents');
            
            var thehtml = "<img src=\""+poster+"\" class=\"floatright\">";
            thehtml = thehtml + "<h2>"+title+"</h2>";
            thehtml = thehtml + "<p class=\"genre\">"+genre+" - first aired in "+rlseyr+"</p>";
            thehtml = thehtml + "<p>"+plot+"</p>";
            thehtml = thehtml + "<p><a href=\""+url+"\" target=\"_blank\">View on IMDB →</p>";
            
            cdiv.html(thehtml);
          }
        });
    

This Ajax request is the most important section and it closes off the whole click event handler. We make an open request to the URL defined with a JSON data type. The new function(data) call actually pulls out the request data upon success, so that we can work with the new JSON contents. Data elements may be accessed using dot notation like data.title. If you want to see a full output of the JSON content simply run console.log(data); and then check your JS console.

After the variables have been defined I start creating a string named thehtml. This is concatenated from one string to the next so we ultimately end up with a single string containing all the HTML data. You will notice this gets passed into the #imdbcontents div which then finally closes the callback function. All of this code is very malleable, and so it’s easy to manipulate the position of content or even include other bits of data from the JSON response.

Live Demo – Download Source Code

Closing

It is fantastic to see these online APIs which tie into alternative popular websites. This advancing age of web technology allows more developers access into data systems than ever before. IMDb is just one example out of many popular websites benefitting from an external web service. Feel free to download a copy of my source code and toy around with this API for your own projects.

The post Coding a Dynamic IMDb Webapp using My Movie API appeared first on Treehouse Blog.