Thulcandrian

Jul 08

XOXCO built a miniature taco truck. -

xoxco:

It all started with an email. SiteGoals contacted us out of the blue asking if we would like to participate in a friendly pinewood derby race with other local creatives. There was no way we could refuse!

When thinking about what our car would look like, we naturally gravitated toward food….

Yes, the tacos really are that good.

Nov 27

Teaching Myself a Lesson in Image Optimization

Web performance is a critical component of web development, for accessibility and optimization for mobile among many other reasons. It’s the responsible thing to do and there are many examples of websites that get loaded down with super heavy images and deliver massive payloads. It’s irresponsible.

There are a lot of resources out there for optimizing, and best practices including compression, loading javascript appropriately, etc… One instance that I have seen consistenly overlooked is image optimization, something that can be done simply within Photoshop or using a nice optimizer like TinyPNG. Often, images are passed from designer to developer and miss this critical step. Of course, and with great shame and remorse, it happened to us and here are the results.

With World AIDS Day approaching on December 1st, we were in a push in early November to re-launch our Facing AIDS website. Typically, we make sure to run some performance tests prior to production launch, but we saw more glaring issues with some layout bugs. In a responsively designed site, dealing with CSS bugs for iOS or Android sometimes trump the simple performance tests we could have done. We missed a critical step in the process.

So we launched the site with three rather large PNG’s, each of them each exceeding 500KB. This was a face palm moment, something I should have checked before we pushed to production, but didn’t. These PNG’s needed alpha transparency to fit with another image, so they were actually PNG-24’s, larger than they should have been. I’m not a Photoshop pro, so another member of the team cleaned them up, removed the transparency, updated a background image, and ended up with three images instead of four, and a new total of 219KB for the three images combined.

Just to illustrate the massive savings this had on our website overall, here’s the Web Performance Page results from before and after.

Before:

After:

The results were stunning. A simple image optimization cut our page load by almost 2/3rds, from over 6 seconds down to just over 2 seconds. There’s no doubt we should have done a better job of optimizing from the start, but this is the best example I’ve seen of how much image optimization can save you, or how much it can kill you if you don’t do it.

Needless to say, I’m going to share this with my team and make sure we bake this into our launch process. We missed it this time, and it sure is nice to have a concrete example to point to and say “do this every time, EVERY time.”

Another example of Brown M&M’s built into the web development process. Thanks Van Halen!

Nov 26

kristienvan said: How do I stop wasting being 17?

lazenby:

The only way it is possible to waste being 17 is to wish that you were 18.

When you’re very young, the world is full of atmospheres instead of objects. Think about what memories of childhood are like. They’re memories of how things felt, rather than records of what happened. The red and white dimples that carpet pile presses into your bare knees. How burps smell after you’ve accidentally swallowed pool water. The static electricity that hisses and ticks as you drag your finger across the screen of a television tube. These grains of experience evaporate into the aura of what it was like to be a kid.

Then you get older. The cloud you lived in as a kid starts to fall as hail. Think about how the act of picking a movie changes. When you’re seven, the aura and excitement of WATCHING A MOVIE creeps like a fog into the act of picking one out and it almost doesn’t matter which you choose. Ten years later and you’re weighing this film against that film, comparing tenths of an IMDb star, noticing how Lindsay Lohan doesn’t look like a scuffed Barbie in it, etc.

Life starts to turn dry. The grains of experience no longer evaporate. Instead they collect into little drifts. Lots of people get stuck here. For them the drifts turn into dunes and the dunes turn their lives into a desert of happenstance.

These are the people who need a form to give their life a shape. The same way you pack beach sand into a bucket and flip it over to turn out a cylinder. (It goes without saying that this is what’s happening when you get excited after you’ve bought something.)

The point is that growing up is all too often growth in the wrong direction.

But which other way is there?

About two years before he died, Wittgenstein was talking to somebody who asked him how he could admire a person like (Cardinal) John Henry Newman, who believed in miracles (specifically the miracle of Napoleon being defeated at Moscow because the Pope had excommunicated him three years earlier.) Anyway, the thing Wittgenstein says in response is your answer—

Wittgenstein: Twenty years ago I would have regarded Newman’s action as incomprehensible, perhaps even insincere. But no more…

Somebody: But what changed in you that you no longer think so?

[silence]

W.: I came gradually to see that life is not what it seems.

[very long silence]

W.: It’s like this: In the city, streets are nicely laid out. And you drive on the right and you have traffic lights, and so on. There are rules. When you leave the city, there are still roads, but no traffic lights. And when you get far off, there are no roads, no lights, no rules, nothing to guide you. It’s all woods. And when you return to the city you may feel that the rules are wrong, that there should be no rules.

S.: I still don’t understand.

[silence]

W.: It comes to something like this—If you have a light, I say: Follow it. It may be right. Certainly life in the city won’t do.

A bit of insight this morning.

Nov 15

Blue Beanie Day

Web standards day, November 30, 2013. I’ll be sporting my blue beanie.

bluebeanieday:

The Blue Beanie Day 2013 photo pool on Flickr is officially open. Take a photo of yourself wearing a blue beanie and dive in. It’s okay to preload Blue Beanie Day photos. Start shooting now!

image

Nov 07

Nancy Wake, who has died in London just before her 99th birthday, was a New Zealander brought up in Australia. She became a nurse, a journalist who interviewed Adolf Hitler, a wealthy French socialite, a British agent and a French resistance leader. She led 7,000 guerrilla fighters in battles against the Nazis in the northern Auvergne, just before the D-Day landings in 1944. On one occasion, she strangled an SS sentry with her bare hands. On another, she cycled 500 miles to replace lost codes. In June 1944, she led her fighters in an attack on the Gestapo headquarters at Montlucon in central France.

Ms Wake was furious the TV series [later made about her life] suggested she had had a love affair with one of her fellow fighters. She was too busy killing Nazis for amorous entanglements, she said.

Nancy recalled later in life that her parachute had snagged in a tree. The French resistance fighter who freed her said he wished all trees bore “such beautiful fruit.” Nancy retorted: “Don’t give me that French shit.”

” —

"Resistance heroine who led 7,000 men against the Nazis," The Independent. (via madelinecoleman)

Great story here.

(via everyoneelseistooloud)

Oct 21

Brown M&Ms from Van Halen on Vimeo.

Van Halen had an infamous rider in their contracts with promoters during the 80’s when they were touring the nation non-stop - no brown M&M’s backstage. A lot has been made of rock star excess with regard to their contract riders. A photographer named Henry Hargreaves even created still life’s of the more audacious ones.

Diamond Dave does a good job of explaining just why Van Halen put such an odd demand in their contract. They were attempting something new with their huge stage setup and most promoters across the US weren’t prepared for this massive stage. Some promoters didn’t even bother to read the rider. Van Halen knew this, and they also knew that in order to be safe, their promoters needed to follow their advice on stage setup to the letter. Placing an odd clause in the middle of the rider was an early flag on knowing that their stage was set up properly. Say what you will about Van Halen’s rock n’ roll excesses, but the men were professionals.

Healthcare.gov was attempting to build an entirely new system. One that was arguably larger and more complex than anything that had been attempted before. Documenting that process (which I’m sure they did) should have included some brown M&M’s - so what does that mean?

Code errors and deficiencies

Which gets to the recent healthcare.gov fiasco. Much has been made about what went wrong and how woefully the new website has underperformed. It’s a mess. A recent post on TechDirt surfaced the news that even a javascript plug-in for jQuery called DataTables was a pirated version, one that didn’t feature the JPL or BSD software license for the project. I’ve used DataTables on a project, I knew we needed to have the license in place, even on the minified version we pushed to production. That’s Web Development 101. So how did that slip past the healthcare.gov implementation team?

My guess is they were working feverishly just to get the site launched and did the bare minimum in testing, across the board. There was one report of 56 javascript files being imported on a single page. 56! No page requires that much javascript to run - they were patchworking their way to a functional website and validation scripts and developer code comments must have gotten pushed to production along with everything else. It wasn’t a clean launch.

And regardless of whether or not the site was ready functionally, you do not go to production without having cleaned up the code to some degree. They were missing some processes that could have cleaned up their code and would have at least launched a website that might have been functionally deficient, but not embarrassingly untested - each glaring error is just piling one on top of the other now.

Building in Brown M&M’s

Web Development is about getting things to work in the browser, but in the midst of that process, you have to have some standards to fall back on, some checks in the process to ensure that what you’ve built doesn’t just work, but is maintainable going forward and offers a reasonable experience to anyone who visits the site, regardless of the technology they might be using - phone, tablet, or Windows PC running Internet Explorer 6.

One way the development teams I’ve worked on building broadly supported websites is to validate our code against W3C standards. Here’s the thing about validation - it isn’t 100% necessary. No one who looks at a website via a browser will know for certain that the website meets W3C standards by looking at it. The website will still work, the images will still display, the data you submit will still go to the server.

You have to test for it. It’s a test that takes you out of the normal workflow of development. It slows you down. To me, that’s the point. It’s a brown M&M - something that you put there to make sure you have done all the other things you are supposed to do to build a complex website. As I’ve transitioned from in the trenches developer, to tech lead and architect, I’ve used validation as a way of ensuring that other members of the team are accountable to that standard too. Validation lets me know that they’ve done the cleanup - they’ve verified their work independently and are ready to push their code to production. In cases where code doesn’t 100% validate, they have answers for why. Sometimes, that code gets pushed to production anyhow, because we know why that error is there and we know it won’t affect the site. Other times, it requires us to fix and rewrite code to meet that standard. But we test and verify the solution, every time.

Healthcare.gov could have used some brown M&M’s in their documentation

It’s clear with some of the errors in licensing and javascript loading that the process for building healthcare.gov was broken. I am sure there were talented engineers working on the site. Everyone knew the importance of that website to the Department of Health and Human Services and the Obama Administration. There were smart people who were genuinely invested in the success of the site. But the rush to production meant that key steps were missed in the process. Steps that would have slowed everyone down and would have surfaced some of the deeper errors that caused the site to crash.

Validation and Testing are a process that give cover to engineers and managers alike. It sounds like the pressure on the healthcare.gov team was extreme - but that’s no excuse for pushing a site live that hasn’t been properly tested and validated. Documenting and detailing those requirements up front - in the planning stages, before coding even begins, ensures that those proverbial brown M&M’s aren’t left in the catering area - evidence that the system wasn’t built to all of the required specifications.

Lack of valid HTML code didn’t cause healthcare.gov to fail. It could have run just fine with or without that W3C seal of approval, but a lack of sufficient testing and validation surely contributed to the downfall of the site on launch day. There were brown M&M’s all over that website.

Oct 18

Learning from healthcare.gov

image

The fallout from the launch of healthcare.gov continues to hover over the government IT community. Many articles have been written that address the deficiencies in IT procurement, technical issues, and even who might really be at fault.

Of course, once it moves to Congressional hearings, the potential for constructive solutions becomes inversely proportional to the length of the soundbites and diatribes delivered by attention hungry members of Congress, eager to score points. Few of them grasp the technical complexity of the project, and fewer still understand the real solutions required to ensure a failure of the scale of healthcare.gov doesn’t happen again.

The most damaging headline that I saw came from the Washington Post - Meet CGI Federal, the company behind the botched launch of HealthCare.gov. As an employee government contractor, there’s a certain amount of schadenfreude seeing a competitor’s name anchoring such a brutal headline.

It’s also sobering. Former colleagues work there and I’m sure they are feeling the brunt of this. If anything, I empathize with them - I can only imagine how much work sucks for them right now. We have all been involved in projects that lacked sufficient requirements or documentation, had extremely tight deadlines, and set development teams on a path to failure. The difference with healthcare.gov is the visibility of their failure. They are the Icarus in this situation, flying much closer to the sun than the rest of us. To a certain extent, we’re all flying with wax wings in government IT.

Which is why the healthcare.gov fiasco needs to result in some real frank lessons learned. It’s doubtful that CGI Federal (a publicly traded company) will publicly admit to the faults and deficiencies that led to the very public failure of the website (and CGI Federal is one of many contractors involved in the development of the site) - but for the good of the next large projects that plan to launch, who might be currently gathering requirements or seeking a similarly ambitious solution - these projects need to know what went wrong. Technical failures, server failures, deficiencies in technical architecture, design or even the minute details of improperly coded javascript.

Failure becomes all the more tragic and infuriating when nobody learns from those mistakes and nothing changes as a result. The GSA Center for Innovation should make a point to get some off-the-record lessons learned. Data behind the launch, key failures, fixes that have been implemented should all see the light of day. There is probably too much risk in identifying the failing parties by name (in that context) and I am not suggesting an abdication of accountability for the failures - but part of the accountability process should be a thorough airing of the failures to the public and to the government IT community. It would be an additional epic failure to not learn what went wrong. We must ensure those same mistakes are never again repeated.

A public technical report, that’s an open government solution we could all be proud of.

Oct 03

Jennifer Dewalt: After 180 Websites, I'm Ready to Start the Rest of My Life as a Coder -

This is so cool, I just had to share it. Such an impressive feat.

jenniferdewalt:

I learned to code by building 180 websites in 180 days and I’m really looking forward to a vacation!

For the last six months I’ve been putting in countless late nights and stressing out over many near failures but it was all worth it to reach my goal.

The details of what I’m talking about can…

May 25

A Call to Action -

This article woke me up to today, literally and figuratively. It calls attention to the unsexy masses, neither the poorest of the poor nor the richest of the rich.  As a nation and a society, we can only be as great as the least among us, they are the rudder that guides the ship. Want to do my part to help.

Apr 15

Beyond treating individual letters as physical objects, the human brain may also perceive a text in its entirety as a kind of physical landscape. When we read, we construct a mental representation of the text in which meaning is anchored to structure. The exact nature of such representations remains unclear, but they are likely similar to the mental maps we create of terrain—such as mountains and trails—and of man-made physical spaces, such as apartments and offices. Both anecdotally and in published studies, people report that when trying to locate a particular piece of written information they often remember where in the text it appeared. We might recall that we passed the red farmhouse near the start of the trail before we started climbing uphill through the forest; in a similar way, we remember that we read about Mr. Darcy rebuffing Elizabeth Bennett on the bottom of the left-hand page in one of the earlier chapters.

In most cases, paper books have more obvious topography than onscreen text. An open paperback presents a reader with two clearly defined domains—the left and right pages—and a total of eight corners with which to orient oneself. A reader can focus on a single page of a paper book without losing sight of the whole text: one can see where the book begins and ends and where one page is in relation to those borders. One can even feel the thickness of the pages read in one hand and pages to be read in the other. Turning the pages of a paper book is like leaving one footprint after another on the trail—there’s a rhythm to it and a visible record of how far one has traveled. All these features not only make text in a paper book easily navigable, they also make it easier to form a coherent mental map of the text.

In contrast, most screens, e-readers, smartphones and tablets interfere with intuitive navigation of a text and inhibit people from mapping the journey in their minds.

” —

Scientific American explores the reading brain in the digital age. Also see the death of the book through the ages, the publishing world on future of print and writers on the future of books. (via explore-blog)

This is such an interesting take on what it means to read, and what our brains do to anchor what we’ve read - perhaps the pages actually do matter? What does this mean for ebooks, or even reading on our laptops? What other physical signposts do we have?

(Source: , via explore-blog)