daverupert.com

Hidden Expectations

Mon, 01 Aug 2016 00:00:00 -0500

This job never came with a manual. If you’re like me, you got into the business of building websites writing bad teenage poetry or photoshopping crude posters for your band. Eventually, you learned the skills to put your creation on the Web and became addicted to the thrill of instant self-publication.

Over the years I’ve come to realize that most difficult part of making websites isn’t the code, it’s the “hidden expectations”, the unseen aspects I didn’t know were my responsibility when I started: Accessibility, Security, Performance, and Empathy.

Accessibility

Sir Tim Berners-Lee designed the Web to deliver Hypertext to any computer, on any hardware, anywhere in the world. Behind a myriad of devices are a myriad of people with none or any combination of visual, auditory, cognitive, and/or motor disabilities. Modern accessibility abides by the POUR acronym, which (to oversimplify) expects your website to be screen-readable, keyboard-navigable, have easy-to-read content with a sensible document structure, and be usable on any device.

It’s all too easy to mess this up. You can make a tabbed interface with three lines of JavaScript or a checkbox hack, but it would likely be unusable for non-sighted users. You can make custom-styled <select> boxes using <div> elements, but sacrifice all the accessibility features of the native form control. Our cleverest implementations often fall short.

And it’s complicated. If I’ve learned anything from 3 years of The Accessibility Project, it’s easy to get discouraged by such a nuanced field. Just when I’m ready to quit trying, I remember that (by some estimates) 1 out of 5 people –whether temporary or permanent– count on us doing a good job at Accessibility.

Security

Security and its twin sister Privacy have made quite a few headlines in the last few years: Heartbleed, Shellshock, DNCLeaks, and a rash of security breaches for many major online retailers. The consequence? Our personal information leaking out like sewage into the Dark Web.

Those of us building websites probably all need a better working knowledge of common attack vectors: XSS, CSRF, click-jacking, Social Engineering, etc. And how to defend against those dark arts: SSL, enable CORS on both the client and server, strict Content Security Policies, encrypting all sensitive data, and anonymizing any personally identifiable information (PII). We need to 2-factor authenticate everything. Our sites, its systems, its data, its settings need to be secure by default. Similar to how cars have seatbelts.

Designers may be quick to wring their hands of such a complex and technical responsibility as a problem for neckbeards to solve. However, Security and Privacy start with design. In a talk titled “How Designers Destroyed the World”, Mike Monteiro retells the story of a woman who’s sexual orientation was unintentionally revealed to her conservative father due to a flaw in Facebook’s privacy settings. Monteiro makes a convincing argument that situations like this are not a technical problem, they are a design problem.

So Security and Privacy are actually all of our problems. Personally, I expect this space to heat up now that high profile political and corporate hacks are happening on the regular.

Performance

Web Performance is a hot topic. Faster websites make happier users, who click more links, who generate more revenue. It’s the perfect meeting point between User Experience and Business Analytics.

Performance is measurable, but not visible. Web Performance is almost a feeling that we use metrics to diagnose. It’s difficult to keep top of mind. Performance tends to be the last step of our build cycle yet design decisions that directly impact overall performance happened months ago.

To top it all off, our standards are probably too lax. How we measure, describe, and collectively perceive “fast” probably needs rehabilitation as well.

It’s hard work to stay on the bleeding edge of speed. Everything changes every six months. It takes a mix of server, front-end, automation, and teamwork kung-fu but the good news is that Performance can be 💸 very rewarding 💸.

Empathy

All of these can be summed up in a simple word; Empathy. Design is ultimately about making connections with people. Dealing with humans (who have emotions and unlimited number of contexts) requires empathy for what they might be experiencing.

In their book Design for Real Life, Eric Meyer and Sarah Watcher-Boettcher set the bar for Empathy fairly high. I think it’s a good bar. They introduce the idea of “stress tests”, that is to say, does our design and software serve people who aren’t in an ideal state? Do our animations or witty bot responses frustrate users who have zero fucks to give? In most situations I’d wager; Yes.

It’s difficult to sustain the level of empathy required to build software that actual real, emotional people use. The Web’s greatest strength, human connectivity, requires that empathy. Mastering Empathy means we can make the Web and possibly the world a better place for everyone.

Managing the Hidden Things

It takes a level of constant vigilance to manage the hidden things correctly. Accessibility, performance, security, and content audits easily slip through the cracks as budgets and timelines slim down. “Get it done” trumps “Do it right”. In fact, “Do it right” is a bit of a problematic call-to-arms, because the moral implication has an air of religiosity to it. What’s “moral” and “right” to one person may be different to another. Unfortunately, “Function well and protect the individual legal rights and dignity of every user” doesn’t make a good soundbyte.

The only way I’ve found to deal with the immense responsibility of these hidden expectations is to take each task up for a season. I personally feel myself embarking on a season of Security. Lo, heavy is the tin foil hat…

Becoming a generalist in these areas can be difficult. Discovering who to trust and what information is current is half the battle. To add insult to injury, some communities (like Security and Accessibility) have vocal minorities that reject novices becuase they have the potential to create more problems than solutions. So be careful, thar be dragons.

If there’s any silver lining, it’s that more practice makes it easier to be more mindful. Over time, it’s less difficult to jump back into a different mindset if you’ve dedicated yourself to one for a season. If you have a team doing these things, it’ll be easier to remember too.

It’s important to know your blindspots. When in doubt hire a professional dedicated to one of these trades for help. Don’t neglect the things you cannot see or measure.

Solvable Chunks: One Week Video Game

Fri, 29 Jul 2016 00:00:00 -0500

‘Twas late Sunday night and I got an idea for a multiplayer HTML5 game using canvas, web sockets, and gyroscopes. I tossed and turned mulling it over. On Friday night Chris Coyier and I were scheduled to do a live Shop Talk Show at Web Design Day in Pittsburgh. As I lay awake staring at the ceiling, I realized I might be able to pull it off. I would call it Global Defense!

Play Global Defense

Solvable Chunks

To build the game I broke the project up in to something I call “Solvable Chunks”. Breaking a design or idea into smaller pieces, while maintaining a big picture, allows you to prototype each piece of necessary functionality with the aim to inform your design and timeline.

To me, a solvable chunk is a problem I think I can solve in about 4 hours. The 4 hours is relevant because -as a parent- it’s roughly the amount of time I have after my kids go to bed. It’s also the length of a morning or afternoon where you can prototype while pretending to check your email. Solvable chunks is maybe something we do naturally, but applying a light framework around it has really helped me quickly create and maintain momentum.

When working on a chunk, I’m always aware that a problem can give birth to a myriad of baby problems. Knowing that, over thinking or scoping anything beyond that first or third chunk is futile because what I discover in those early stages will dramatically affect what happens in later stages. I have the big idea in mind, but I let those later stages be intentionally vague.

Solvable is important too. At all costs you want to keep momentum on a prototype. Keeping problems small and solvable helps you do this. Losing momentum means it will be more difficult to jump back into solving complex tasks. If by the end of 4 or 8 hours you’re still not finished, that’s okay. You should now have a better idea of what it would take to finish and if the current design is endangering the timeline.

At the end of your chunk, share and document your learnings with your team. If you’re working solo, keep a development journal you can reference later.

Using prototypes you’ll be able to make better timeline estimates if you do a little bit of the work up front. You can choose to keep iterating, redesign to be something more minimal and timeline efficient, or adjust the timeline.

The following is a night-by-night, chunk-by-chunk, breakdown of how I built Global Defense.

Monday: Asteroids

See the Pen Global Defense v1: Make asteroids fall by Dave Rupert (@davatron5000) on CodePen.

I didn’t know much about drawing in canvas, so my first chunk was learning to draw falling-circle shaped asteroids. Circles have x, y, and radius attributes. Making them fall from the top was simply a matter of increasing the y value every frame and splicing the asteroid object from the asteroids array when it hit the bottom of the screen.

// Move the Asteroids
for(var i = 0; i< asteroids.length; i++ ) {
  var asteroid = asteroids[i];
  asteroid.y += 1;

  if( asteroid.y > h ) {
    asteroids.splice(i, 1);
  }
}

// Draw the Asteroids
for(var i = 0; i< asteroids.length; i++ ) {
  var asteroid = asteroids[i];

  ctx.beginPath();
  ctx.strokeStyle = '#0CF';
  ctx.arc( asteroid.x, asteroid.y, asteroid.radius,  0, 2 * Math.PI );
  ctx.stroke();
}

Tuesday: Shooting

See the Pen Global Defense v2: Make bullets shoot by Dave Rupert (@davatron5000) on CodePen.

I originally wanted lasers to shoot the asteroids like Missile Command or Asteroids, but as I thought about it some I realized a “bullet” is really just a tiny asteroid that goes up instead of down! I already had the code for this, so I inverted my asteroid code to make bullets.

// Move the Bullets
for(var i = 0; i< bullets.length; i++ ) {
  var bullet = bullets[i];
  bullet.y -= 2;

  if( bullet.y < 0 ) {
    bullets.splice(i, 1);
  }
}

Allowing the code from the prototype to inform the design saved me lots of time and I attribute this to being the reason the project was successful.

Wednesday: Collision, Damage, and the Planet

See the Pen Global Defense v3: Aim, Collision, and Damage by Dave Rupert (@davatron5000) on CodePen.

Now I needed the bullets to destroy the asteroids. Searching the web for “canvas circle collision detection” took me to an MDN article about 2D game development. There was my answer in JavaScript. I had to modify it a bit, but it worked and bullets could now splice() asteroids.

// Detect Bullet/Asteroid Collisions
for(var i = 0; i< bullets.length; i++ ) {
  var bull = bullets[i];

  for ( var j = 0; j < asteroids.length; j++) {
    var ast = asteroids[j];
    var dx = bull.x - ast.x;
    var dy = bull.y - ast.y;
    var distance = Math.sqrt(dx * dx + dy * dy);

    if (distance < bull.radius + ast.radius) {
      // Collision detected!
  }
}

Yay free code! The code-informed design decision to switch to circles already started paying off in speed.

Damage was an easy patch. Each asteroid would get a randomized hp (hitpoint) attribute. And the radius on each draw() cycle would now be based on the hp * asteroidSizeModifier. After every collision, damage would be applied, affecting the radius.

if (distance < bull.radius + ast.radius) {
  // Collision detected! Remove bullet.
  bullets.splice( i, 1 );

  // Make asteroid take damage
  if(ast.hp - 1 === 0) {
    asteroids.splice( j, 1 );
  } else {
    ast.hp = ast.hp - 1;
    ast.radius = ast.hp * asteroidSizeModifier;
  }
}

The last chunk was the planet. After some thinking, I realized planets are just very large asteroids! I already had this code and the collision detection. It came together quickly. Again, that code-informed design decision was paying off in dividends.

Thursday: Math and Socket.io

On Thursday I was traveling all day on a plane to Web Design Day. This worked out well for the project because I had to pull it off of CodePen to my localhost begin web socket work using Node and Socket.io.

I started by doing a lot of High School level math. I’m surprised I didn’t get escorted off the plane. Eventually I understood Math.tan() and y=mx+b enough to hook give the bullet a slope as it travelled upwards based on my Surface’s gyroscope.

Socket.io, a very complex web socket thing, turned out to be easier than imagined.

On one page there’s a game board, on another a button that says “Fire”. When the fire button is clicked, it emits a custom event called fire. Attached to that event you can send data. After some tinkering I realized I could just send the calculated slope of the device. Emitting a small packet of data is good.

function handleClick( event ) {
  socket.emit( 'fire', { slope: slope } );
}

The server hears that event and responds by emitting that fire event and its data out to all the other connected clients (i.e, the game board).

socket.on('fire', function(msg) {
  io.emit('fire', msg);
});

When the game board screen hears a “fire” event, it will push() a bullet object into the bullets array with the slope from the packet of data. The draw() function in the next requestAnimationFrame will give it a starting x,y coordinates and start animating the bullet.

socket.on('fire', function(msg) {
  bullets.push(msg);
});

I also learned that VS Code is a really great text editor for building and debugging Node applications. You can (re)launch your server by hitting F5 and even setup a debugger to step into objects and functions just like a web inspector. That feature alone may have secured Code as my editor of choice going forward.

Friday: UI, Polish, and Demo!

Photo by Brian Muenzenmeyer

On Friday I used my new found canvas skills to rough out a UI. This has a “Draw the rest of the owl” feel but everything below was optional. I could have played the game without this stuff, but it was a little more exciting with it.

I did some refactoring:

Improved the single player mode and game joining system.
I added a simple polygon for a ship, but its position affected the initial y-coordinates of the bullets.
Adding a bit of responsiveness for a multidevice strategy means minor refactoring of the ship and planet to be scalable.

And added some nice to haves:

I made a defcon variable to increase the chance of randomization.
I added a score to give the game a bit more of a point.
I downloaded a font from DaFonts for the UI text; score, planet hitpoints, and defcon level.
Made the earth change color for 12 frames when hit.
I bought a domain name and forwarded the DNS.

And that was it. I had a working game. The demo during the live Shop Talk Show went okay. Live demos are always tough, and it’s impossible for me to test 200 simultaneous clients, but it held up and I think people had fun. Bullets never stopped flying.

The next week

Over the next week I built out a punchlist of all the things I learned I needed. I took the same Solvable Chunks approach to finish it out. Most of these chunks went a lot faster. By the next Friday, a week after the demo, I was ready to share it.

Launch went well, except I had a bug where the game would never start. So I uh… fixed that.

There are still have some things I’d like to do, but I’ve learned through this process that each feature adds about another day of work. Making the asteroids more geometric instead of circles? 1 day. Making the bullets lasers instead? 1 day. Progressive web app? 1 day. The list goes on, the day job is back in full effect, and I’ll have to take it one chunk at a time since there is zero momentum. Or I’ll start another project ;)

Summary

Global Defense is a game I built in my spare time. I had a playable prototype in a week and launched it in two weeks.

Along the way, I worked in solvable chunks and let the code from the prototype inform some of my design decisions. This saved uncounted hours and allowed the product to be delivered quickly and on time. Working on a tight timeline forced me to be practical and reduce scope as much as possible. Getting to a minimum viable product meant understanding that every feature would result in another day of work.

I had fun building it and learned a lot about canvas, gyroscopes, and websites with high-concurrency, realtime, cross-device communication. Those are all things I can apply to my work immediately. I’ve also had the chance to have conversations with people from Microsoft Edge and Google Chrome about it, not too shabby.

I think the greatest takeaway, even though it’s low-budget and still has a prototype feel, I built and released my first game other people can play. That is very exciting and I hope there’s more in the future.

The #davegoeswindows Finale

Tue, 19 Jul 2016 00:00:00 -0500

It’s been one year since I uprooted my dev environment and made the switch to Windows. I’m happy to share that after a year of ups and downs, I’ve made the decision… dramatic pause …to… more dramatic pausing …stick with Windows.

Why I’m Staying with Windows

It’s hard to lay out reasoning for switching operating systems without fans of the other operating system being offended and offering endless well actuallys, so let me say this: this is less about declaring a winner, and more about trying something new. I tried something new and I liked it enough to stay with it.

So here are the reasons I’ve decided to stick:

Edge’s recent announcement of Progressive Web Apps on Windows 10 is a major factor. I love the Web and I’m voting with my dollars. I’m similarly considering a switch to Android.
Windows 10 is really great. The best part has been watching it iteratively keep getting better in the Insider Fast Track.
In Windows, HTML/CSS/JavaScript are first class citizens. So are Node apps.
I’m inspired by Microsoft’s view of technology.
Bash on Ubuntu on Windows (aka Windows Subsystem for Linux, aka WSL) is a game changer.
I like the balance it brings to Shop Talk. Advice podcasts should have different perspectives built in to them, not just re-enforcing a monoculture.
Windows gets me excited about hardware: touchscreens, VR, GPUs, 3D webcams, lots of stuff that’s not offered on Mac product line.
I’ve started making some video games and want to play with VR, Windows is the best platform for VR.
I used to believe that Apple was the pinnacle of hardware, software, and design. Apple is still best at “Things just work™”, but I do not believe they’re at the top of any of those categories anymore.

There are also lots of little things I’ve picked up from tumbling down the Microsoft product line. I like Edge. I like OneNote. Groove, my Rdio replacement, is maybe the best music service out there. Visual Studio Code is pretty great, especially for writing Node apps. All those little things add up to a positive experience overall.

What I’m Pensive About

Any major life decision wouldn’t be noteworthy unless it was frought with uncertainty. Here’s what I still wonder about:

Windows Subsystem for Linux (WSL) is promising, but has some problems.
There needs to be a good looking, 256-color, tabbed command line interface. What’s available now feels antiquated.
Apps crashing. Whether it’s Twitter, Edge, Slack, my Wi-Fi drivers, or some other piece of integral software; apps stalling out or wiping off the screen causes frustration every two weeks or so. Requires reboots, which also feels antiquated.
Web design and development tools are still better on macOS.
Detangle myself from Apple services (Photos, iCloud, iBooks, iTunes, etc) is work. Not ultra necessary, but the benefits of the ecosystem rapidly diminish outside of it.
I don’t want to hotswap one ecosystem-dependency for another. I want to be more loosly coupled to the platform.
Coworkers are on Mac. In general this is okay, but being an outlier means I’m responsible for my own tech workarounds.
The CTRL key still kinda bothers me.

The apps crashing issue could be a quality issue, a RAM issue, or possibly related to Insider Fast Track updates. It’s hard to judge when using “beta” software. I’ve considered scaling back to the Slow channel after this experiment is over.

What about #davegoesubuntu?

This comes up a lot. I would probably enjoy it, but everytime I start to think about it I hear this quote in the back of my mind:

Linux is only free if your time has no value. –Jamie Zawinski

At the risk of ruining my “developer cred”, I need a certain amount of abstraction for my day-to-day machine. I have little interest in hunting down and manually installing drivers to make things work.

Also, with Windows Subsystem for Linux now at my fingertips, in some ways #davegoesubuntu is already underway.

A new machine for a new era!

While the Surface Pro 3 furnished by Microsoft has served me well, I’m thinking it’s time for an upgrade. In fact I’m considering switching up my whole setup.

If all goes well, my new setup will look something like this:

2016 Razer Blade 14”
Razer Core with Nvidia GTX 1070
Kindle Paperwhite (to replace iBooks/iPad)
Daydream Compatible Android (when available)
- I’d also consider a Surface Phone, if that’s not vaporware. I got thoughts on how to save Windows Phone tho.
HoloLens if Microsoft wants to send me one of those (wink wink)

It’s a chunk of change, but I feel like the Razer Blade with the Razer Core unlocks what I like about the Windows ecosystem. As I’ve began dipping my toes into WebGL, gamedev, and VR; I think I’d benefit more from a quadcore, a nice GPU, and at least 16GB of RAM (for development). And the outboard GPU will be sweet for games.

This year has taught me a lot about device limitations and integrated GPUs, so I’ll be sure to test on more underpowered hardware.

So I guess I’m a Windows user now…

This decision has been possibly the longest “What computer should I buy?” transaction in recorded history. There’s a sense of personal accomplishment of trying something new and sticking with it for an entire year. I think I’ve benefitted from it, my perceptions surely have changed. It’s weird how much we define ourselves and build factions around the technology we purchase.

It’s a lot of effort to uproot the core of your workflow, like an operating system and a browser, but it’s nice to know you won’t die if you change a piece of software. And you may even like it more in the long run. At least that’s my experience.

Well, that wraps up a whole year of self-experimentation. Probably won’t do another one of these for awhile.

Before I sign off, I want to say thanks to Rey Bango for orchestrating this whole experiment and helping me out when I felt like my computer was going up in flames. Thanks to Ryan Joy for helping me with Windows and Azure stuff (still have to write an Azure post). Thanks to John Shewchuk for the wonderful conversations at Build. Thanks to Helena Li and Danilo Bordini for their help at Build as well.

And special thanks to anyone who commented on this blog or reached out on Twitter along the way, it was helpful beyond words.

A Standard System of Measurements?

Thu, 07 Jul 2016 00:00:00 -0500

Lately I’ve been thinking about how the Web could benefit from a Standardized System of Measurements, especially in how we discuss performance.

I was pleased to find this video where Paul Irish and a consortium of folks are discussing how to measure User Experience (delivery, paint, jank, etc) in Progressive Web Apps.

Collectively defining our own standards

While those big brains think on how to measure real world performance¹, maybe there’s something us “normies” can do in the field.

I’m beginning to believe that front-end developers need to normalize how we perceive and test our sites; and not putting it lightly, it must be Mobile First. I believe using “Chrome on my quad-core desktop” as a baseline skews our lens of performance perception the wrong way.

If the quasi-scientific Web Community were to collectively agree (yes, I realize this will never happen) to use the same testing environments, like Science, it could help eliminate vanity metrics and produce better comparisons and better practices. Here’s my proposal, a starting point, with Mobile First as a guiding principle.

Throttled to 3G Good/Fast (~750kb/s with ~40ms RTT latency)
- This emulates still-common 3G signal and bad wifi (aka, lie-fi).
- Fiddler, Charles, or Web Inspector can throttle to 3G.
- WebPageTests can run at 3G.
Tested in Chrome on actual Nexus 5X
- Android has ~80% global mobile marketshare.
- Nexus 5X is probably a good example of a “median” Android device.
- USB inspecting is Mac and Windows compatible.
- Chrome is currently the most advanced mobile browser.
- Real devices have CPU, GPU, and memory limitations that our quad-core super computers don’t. Alex Russel talks about this in his Google I/O 2016 talk.

All measurements would be based off of those two scenarios. You could build and test your websites with that little device tethered out to the side. This could be accompanied by a second teir of test scenarios that, in the interest of simplicity, are optional:

Tested on Edge w/ multitouch screen
- Default browser for Windows 10
- Windows has a ~80% global marketshare
- 10-point touch PointerEvents
- Historically lacking in feature support
Tested in Safari
- Default browser for MacOS and iOS
- Slower annual release cycle
- Currently lowest on HTML5Test
Tested on Opera Mini
- Harshest of all proxy browsers
- Simulation of when things fail
- Ignores some CSS, no fonts, low JavaScript support
- No asynchronous JavaScript
- Arbitrary JavaScript execution timeout
Tested in Firefox
- Dependable “median” rendering and functionality

Together these cover the high and low end of bandwidth, the high and low end of browser feature support, and some of the high and low end of global market share. I’ve also tried to limit this to an “affordable” number of devices.

I don’t think this replaces a robust device lab or a browser support matrix based on your own company’s stats, but I do think it’s an honest mirror to reflect our work. And covering these bases would make the edge cases more tolerable.

You can develop your sites however you want, but by giving ourselves limitations we can do away with vanity stats and get an honest look at how our servers, HTML, CSS, and JavaScript frameworks are performing.

I don’t actually own a Nexus 5X, but if enough people find this reasonable, I’d glady pony up the money for one. Heck, maybe Google can cut us an awesome discount if enough people are interested.

A neat quote from someone in that meeting is “We’ve done a ton of magic to make scrolling awesome because scrolling is the primary interaction. Also tapping links. Those are the built in interactions the Web gives you… If we scroll and tap on a link, and nothing happens, what have we won?” And I love that. Let’s not break those things. ↩

Ruby on Rails on Bash on Ubuntu on Windows

Tue, 21 Jun 2016 00:00:00 -0500

After getting Jekyll on Bash on Ubuntu on Windows¹ up and running I said my next challenge was getting Ruby on Rails and I have some good news:

You’ll see Linux is being reported as the Operating System. That’s because Bash on Ubuntu on Windows is Linux, just with a few weird compat bugs (but doesn’t normal Linux also have those?).

Eventually, something like a standard “Install Rails on Ubuntu” tutorial should work on Bash on Ubuntu on Windows, but at the time of writing neither rbenv nor rvm work. Ideally you don’t sudo gem install, but for this environment everyone who tested needed root permissions. So here we go…

Install the Linux Subsystem

First, you’ll need the Linux subsystem. If you’ve already got it installed, you can skip this.

Update to Windows Insider Fast Track version >14316
Settings > Updates & Security > For developers > Check “Developer Mode”
Open “Windows Features” (from Cortana) > Check “Windows Subsystem for Linux (Beta)”. Restart.
Open Bash.exe for the first time to install Ubuntu.

Install Ruby

You’ll need to install Ruby 2.3. If you’ve already tried the Jekyll install or done this, you can skip this section.

First, let’s make sure you’re root to update and install make and gcc compiler:

$ sudo -s
$ apt update
$ apt install make gcc

You may get E: Sub-process /usr/bin/dpkg returned an error code (1) errors, while alarming, they don’t prohibit progress. Next, add the Brightbox-maintained Ruby libs (still not sure if this is the best option):

$ apt-add-repository ppa:brightbox/ruby-ng
$ apt update
$ apt install ruby2.3 ruby2.3-dev ruby-switch

Verify Ruby is installed and/or switch if necessary:

$ ruby -v
$ ruby-switch --set ruby2.3

Install Rails Dependencies

Rails has a few dependencies you’ll need to install. The most significant of which is Node ( errrrt… record scratch sound effects ) that is used by the Asset Pipeline to uglify JavaScript. If you already have Node 4+, skip this step.

For Node v4:

curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
sudo apt-get install -y nodejs

For SQLite3:

apt install sqlite3 libsqlite3-dev

For Nokogiri, Rails’ XML parser, you’ll need some XML libs:

apt install zlibc zlib1g-dev libxml2 libxml2-dev libxslt1.1 libxslt1-dev

At the time of writing, there’s a Nokogiri bug in 1.6.8 where iconv tries to install libxml2-2.9.4 and fails. This is happening on Mac and Windows (confirmed). You’ll need to install Nokogiri and force it to use the working version of libxml (2.9.1) we just installed with apt:

gem install nokogiri -- --use-system-libraries

Hopefully this saves you some gem install failure and heartache.

Install Rails

From here it’s a pretty straight forward Rails app:

$ gem install bundler
$ gem install rails --pre
$ rails new testapp
$ cd testapp
$ rails server

Rails 5.0.0.beta3 should now boot up on http://localhost:3000. From a cold start on a scaffolded posts#index with a title and a body, here’s the results:

	Completed	Views	ActiveRecord
Powershell	725ms	696.2ms	1.5ms
Bash	415ms	383.3ms	2.4ms

A 300ms improvement (nearly twice as fast) is wonderful and brings me closer to production server responses.

The Year of Linux on the Desktop

Let me know if you have problems or I messed up. I’m still learning the ins-and-outs of a third operating system. I used to consider myself very Linux proficient, but not anymore faced with a naked install.

I’m very much a “Best Practices” guy and would like to be following the most common convention with the minimal amount of effort. For better or for worse, abstractions like Homebrew numbed me to what was happening behind the scenes. Taking that convenience away has taught me a lot.

Next step is Postgres, Image Processing with Paperclip, Authentication with Devise, and trying to push the limits a bit further.

Thanks to Schneems, Chris, James, and Tom for tech checking this post.

UPDATE: Jekyll on Bash on Ubuntu on Windows is blocked by a libinotify file watching bug. This affects any file watching task (like Sass) that of Ruby and Node workflows depend on. If you want to do modern web development on Bash on Ubuntu on Windows, please vote it up in User Voice. ↩

Dave Goes Build

Thu, 09 Jun 2016 00:00:00 -0500

At the end of March, I was invited out as a part of the #davegoeswindows experiment to attend Build 2016, the annual Microsoft developer conference. Think WWDC or Google I/O, but for Windows developers. Over three days of keynotes, roundtables, breakout sessions, and an expo I was able to learn from and speak candidly with many people at Microsoft. Most of my questions were centered around the state of software, hardware, and where things are going in the Windows ecosystem.

A New CEO, a New Microsoft, a New Perspective on Technology

It all started with CEO Satya Nadella giving the opening keynote on the first day. He started his keynote with three big questions; “Is technology empowering us? Is technology generating wealth? And is technology protecting our privacy?”

Microsoft has a new mission statement about “empowering every person and every organization to such and such…” It’s a great mission statement. It has words. The best words. But as the keynote went on the biggest impression I received was:

Microsoft’s view of technology seems to be “We want your thing to work with our thing.”

I found this view of technology refreshing. I think I’ve gotten tired of Google telling me “This is how you have to build websites now.” Or Apple coming down from the mountain once a year saying “Here are the two new products you will buy this year.”

To be clear, Microsoft is a for-profit business that wants you to pay money for their consumer and enterprise, cloud-based technologies. But how they did it was different. Over the course of Build, dozens of new APIs and SDKs were introduced. It was like the entire Microsoft product line was opened up for developer access. It wasn’t some fast-talking salesman approach, it was almost an open source approach; “Here’s this thing, let me know how it works.”

Microsoft under Nadella is a very different business. In fact, everyone from Microsoft I talked to mentioned this. From the top down they’re encouraged to try new things, even contribute to open source, which for some long time employees was absolutely a foreign concept. Microsoft is a very different company now.

In a lot of ways Windows was Bill Gates and Steve Ballmer’s baby in which they could see no flaw and sought to protect. Nadella, however, was in charge of Azure which requires integrating with non-Microsoft products. That subtle change in perspective cascades down, creating a new Microsoft.

Armed with this new perspective on technology, I further tumbled down the Microsoft family of products at Build. I played with things I had never heard of or already dismissed and I saw things I never thought could exist…

Bash on Ubuntu on Windows

When Bash on Ubuntu on Windows was announced I let out an audible “Holy shit!” I never thought this would happen.

If there’s one thing I’ve learned from #davegoeswindows it’s that a lack of a Linux Bash environment makes modern day web development more difficult on Windows. Most tutorials and readme files for large open source libraries are all written from a Bash point of view, with the occasional hard-dependency on Linux.

In response to this, the team at Windows have somehow managed to get a complete Ubuntu binary (not a virtual machine) running natively in Windows!

After the keynote, I got to meet with a very excited John Shewchuk, a Technical Fellow at Microsoft and host of DECODED (a YouTube show about people who make open source). John knew Build just dropped a bomb on me. I asked about the impetus for such a bold move and his reply was something to the effect of “We know it’s important to a lot of developers.” Again, we we want your thing to work with our thing.

But I had to know how well it worked. John introduced me to Dustin Kirkland of Canonical, one of the people working on the Bash on Ubuntu on Windows project. He graciously fired up his machine and said “What do you want to try?” And I replied “helloworld in ruby”. We created hello.rb and I watched Dustin type the following:

# apt install ruby
.. some matrix stuff happened here ..
# ruby hello.rb

It just worked. No Stack Overflow articles. No installers to unzip from the web. No binaries being maintained by one person. No mingw. Native ruby running in minutes.

Bash on Ubuntu on Windows has a way to go, but the future is bright and it’s set to remove a major blocker in my development environment.

Edge

I learned a lot about Edge at Build. I’m not sure everyone knows this, but Edge has been my browser of choice for nearly 11 months. I repeat: Browser of choice. To me it looks the best and feels the fastest. I have to pinch myself every so often that I use the spawn of Internet Explorer for daily browsing and web development, but it works well.

At the time, Edge had more than 180 million unique users and a growth curve matching that of Chrome’s early days. The good news is Edge is being actively developed with great developer relations and there are lots of new things on the horizon:

Extensions
WebRTC
Push notifications
Automated tests through WebDriver
Read webpages to you with the Speech Synthesis API
Log into websites using your face

The last one was the most impressive. Using the Web Authentication specification (formerly the FIDO 2.0 Web API) and Windows Hello, you will soon be able to log into websites using biometric information like your face or fingerprint.

Visual Studio, Azure, Office, and Skype

Lots of updates to Visual Studio, but the biggest was the Xamarin acquisition. Xamarin is a cloud-based, cross-platform device testing service that now lives inside Visual Studio. Like Browserstack for native apps.

I wasn’t extremely impressed until I saw iOS Simulator running on Windows! There was even an Interface Builder-like tool right there in Visual Studio. In some ways testing iOS apps on Windows is better than on a Mac, since most modern PC laptops have touchscreens you can test touch interactions on without ever leaving your laptop.

Office Add-ins were another surprise. Lots of people use Office every day (like ~1 billion people) and the good news for Web Developers is these Add-ins can be written in HTML/CSS/JavaScript and run as web apps in the native Office clients.

Skype also announced a slew of new APIs as it makes the transition over to WebRTC and bot users. Oh yeah… bots, bots, bots.

Bot Framework

Microsoft is betting big on bots. So big they designed and built Bot Framework, an application and framework that helps you build, deploy, give bots language parsing abilities.

The demo for this was incredible, a PizzaBot (#FunFact: There are more PizzaBots than humans) that used natural language parsing to map to API endpoints. The linguistic capabilities of the bot were trained using a machine learning interface all with zero lines of code.

I find the release of Bot Framework incredible because it’s so counter-current to what other bot platforms are doing. Facebook Messenger wants you to build bots for its platform. Slack would rather have you building bots for their platform. But Microsoft is like “Meh, let’s try to make ‘em work everywhere.”

That’s the style of thinking that I find really refreshing. They’re not just only solving their problem (Skype bots and Cortana extensions) but trying to co-exist in an whole ecosystem of conversational bots and make it easier for developers to be cross-bot-platform.

Cognitive Services

Powering the core strength of the Bot Framework is Microsoft’s Cognitive Services API that emulate human capabilities like Vision, Speech, Language, and Knowledge. These APIs are the easiest way I’ve come across to leverage the power of machine learning for your application.

Need to add image recognition and captioning to your app? It’s almost a one liner. Need to detect emotion? It does that too. Don’t have time to figure out Natural Language Processing on your own? Meet LUIS. These APIs are the backbone of the Microsoft apps that have been making the social media rounds: How old am I? What dog am I? Who is my celebrity lookalike?

The majority of demos on the expo floor were using these services as well, but the best demo was in the opening keynote with Saqib Shaikh. Shaikh, a developer at Microsoft, built an application for his smart glasses that takes a picture and using the cognitive services API it will describe back the environment around him.

What is technology if it doesn’t empower people?

Ink

During the opening keynote, Microsoft’s uncomfortably charismatic Bryan Roper (aka “the Fedora Guy”) spent a lot of time talking about Ink. I didn’t think much about styluses until Bryan threw out some interesting data points about pen usage:

72% of people use a pen for 1hr/day
32% of people use a pen for 3hrs/day

Bryan did a good job demonstrating “the power of pen and the PC coming together”, but most impressive of all is you can integrate Ink into your Universal Windows Applications with just 2 lines of XAML¹

<InkCanvas x:Name="myInkCanvas"></InkCanvas>
<InkToolbarTargetInkCanvas="{x:Bind myInkCanvas}"></InkToolbar>

I couldn’t really imagine implementing something like this on the Web, iOS, or Android. Seems like gallons of code to do well, but here it is for free.

HoloLens

Dave goes HoloLens #Build2016 pic.twitter.com/YBdlvuWr4I
— Dave Rupert (@davatron5000) March 31, 2016

Hell or high water, I was going to put a HoloLens on my big dumb head and after waiting in a few lines, I succeeded! There’s lots to say about this experience and VR/AR/MR in general, but that’s for another post.

The first impression of the HoloLens is that it’s impossibly light. You put it on your head, twist some knobs, and great sound with no headphones projects into your skull. I think here’s where things went wrong.

I have a large head (7 ⅞ hat) and glasses and the device never quite fit right. Enough to tarnish my impression.

The field of view was an issue as well. One common critique of the HoloLens is that it doesn’t extend to your periphery, it’s just a narrow field of view (120°) in front of you. I think this was compounded by the Destination: Mars demo.

Don’t get me wrong, it was amazing to witness Buzz Aldrin walk into the room like a Harry Potter ghost, but you could also see the square outline of the projection in the dark room. It broke the illusion of a seamlessness transition between reality and mixed reality, and felt like I was just watching a movie (which I was). The magic was removed.

I want to give it another try with a better fitting headset. I think it’d be more impressive in higher light situations.

Surface Hub

Dave Goes 84" Wall Mounted TV Computer? #Build2016 pic.twitter.com/EjZHzIROKJ
— Dave Rupert (@davatron5000) April 1, 2016

Now, I want to go on record and say I care very little for the “How do we design for large screens?” question. But seeing one of these wall mounted 84” behemoths in person, I was curious about what in the design of a Universal (aka Responsive) app didn’t scale to the ultra-large screen.

Controls are either in the center of the screen or repeated on both sides. This allows for less walking back-and-forth while presenting.
There are a few “zones” or distances to consider. Imagine a board room with a long table in the middle. There are people close, near, and far away from the screen. This affects type sizes, how small and complex designs can be, etc.
Input methods: People closest to the screen can touch, but people towards the back of the room may mirror the screen on their device.
Privacy is a major concern. You can’t have a sensitive documents like “PEOPLE_TO_FIRE.xls” lingering on the screen when the next meeting walks in. On the Surface Hub, all data is erased after every session when people leave the room, so developers must be prepared for that. Every time your app runs, it’s like the first time.

I wanted to hate this monstrosity but it’s actually a pretty good piece of hardware. Infinitely better than most of the heartaches I’ve seen littering conference rooms across the world. The touch responsiveness was uncanny for how many pixels are on the screen. By the end of the conference I wanted one in my office shed and have started scheming in-office co-op applications specific to the hardware.

Windows IoT

There was a Smart Mirror at Build. I’ve seen Android Smart Mirrors on The Verge before, they’re cool but the Internet of Things is sometimes creepy so I tend to shy away. I almost didn’t attend, but my need for food landed me nearby a demo.

Curiously, it was members of the Edge team giving this talk. They invited a member of the audience to get a selfie taken, then he walked in front of the smart mirror, it recognized him, and it greeted him. Wow!

They mentioned the Magic Mirror repo on Github, I pulled it up dug through the code… it was just a Node app. Then I put it together. The IoT device was just projecting a hosted web app behind the mirror. White text on a black website. Seeing this got me kind of excited to build embedded web experiences on a Raspberry Pi.

An interesting limitation of the Raspberry Pi is that it has 200MB of memory (for page size and JS heap), so animations and fancy JavaScript stuff is probably a no-go.

Thanks for having me, Build

I want to thank Microsoft for having me out to Build. In private backroom roundtable discussions, I got the chance to talk with and vomit my problems on people who are very good at their job and very respectable. They took the feedback to heart and one VP of Product even said, “This is how we get better.”

The most important thing is that Microsoft was listening. Again, and I can’t stress this enough, it feels like an entirely new Microsoft. An organizational change of that magnitude is hard, if not impossible to pull off.

As the Anniversary Edition of Windows 10 approaches I can say without a doubt that things have improved over the last 11 months. It’s great to see software iteratively improve over the course of a year. The new level of transparency and feeling of confidence that comes from Microsoft trying to get “your thing to work on our thing” is better than all the marketing dollars in the world.

XAML is Microsoft’s XML-based user interface markup language, like React but from 2008. ↩

Responsive Product Comparison Tables

Fri, 27 May 2016 00:00:00 -0500

I’m sure it’s not a rare use case, but between working hours I’m a mobile-only user. Young kids mean I need my hands free and not having a laptop in the house has made for better work/life balance. As a result of being mobile-only for half my waking hours, I get the opportunity to see where web designs phoned it in on mobile (pun intended). I could probably write a whole book¹ about where things go wrong, but the summary is designers don’t test their sites on mobile.

The Comparison Shopping Problem

One area that is particularly frustrating is Comparison Shopping. Antithetical to most “mobile contexts” I’ve heard thrown about, I do a lot of comparison shopping for little things (gadgets, gear, design assets, clothing, etc) and big things (cars, computers, home furnishings, etc). It’s never a great experience.

I should take a step back and explain the issue from a technical level. There are only a few tried and true solutions for dealing with tables in a responsive design:

Do nothing and let the table overflow miserably.
Wrap the table in a div with overflow-x: auto; -webkit-overflow-scrolling: touch;
Stack the table, using pseudo elements each row of the table becomes like a definition list.
Add column toggling to the table.
Freeze/Fix the left header column and make visible cells swipeable.

The latter three scenarios are covered excellently by Filament Group’s Tablesaw library. Most comparison shopping tables opt for the “Stack” option. This is probably a great place to start. I think this works well for smaller data sets but with anything with lots of columns or rows, it becomes an unpassable user experience; rows bleed into rows and it’s difficult to understand the context of the data.

I’m not the only one who has felt this problem:

Is there a Wikipedia for open, standardized, and crowd sourced product comparison tables?https://t.co/EkHEMNluj5 https://t.co/NxLw1yqPxl
— Adam Michela (@soopa) May 18, 2016

Of the two links Soopa mentions, one is unusable on mobile and one just gives up entirely and hides the pricing and comparison tables (the only feature on the page).

Workshopping a Solution

Frustrated, I took a stab at fixing this one particular component. UX and accessibility can be improved, feel free to modify and rebound as necessary.

See the Pen Responsive Product Comparison Table by Dave Rupert (@davatron5000) on CodePen.

At smaller breakpoints, the table becomes a carousel of cards. It’s similar to the Swipe solution from Tablesaw, except this presents one column of data at a time and stacks the row header above the data cell. The problem I think this solves is getting all the information about a single product in a single view. I can fix my eyes on one row and cycle through features I care about.

Some guy named Ethan on Twitter mentioned that SBNation has a similar pattern for their playoff brackets:

@davatron5000 I mean, SB Nation’s done that with their brackets. (https://t.co/b9lQQEyfWy) Makes perfect sense.
— Ethan Marcotte (@beep) May 18, 2016

And that leads me to the main point I’d like to make…

Different Patterns for Different Content

We’ve done a great job pattern-izing our designs into reusable components, but patterns need to suit the content. Not all content serves the same purpose and therefore deserves different treatments. I harked on this in a recent post, but a list of movies and a list of coupons should function and look completely different. Similarly, some tables you navigate by the column headers, other by the row headers, others require both to make sense.

As a larger design community, we tend to glom onto existing patterns and trends without regard as to why. We inject card interfaces without considering if that metaphor applies to the content. We overload our marketing pages with saccharine eye candy, burying the lead on our billboard websites.

I’d love to see and read about more hyper-specific solutions that cater to specific content. I recently spent over a year thinking about responsive online coupons, not very exciting but very thought-provoking.

Using prefabricated, road tested solutions from Apple’s Human Interface Guidelines, Google’s Material Design, Twitter’s Bootstrap, and Brad Frost’s Responsive Patterns is always a good place to start, but don’t settle there. My biggest advice would be to turn off the 27” display and use your sites and projects on your phone, there’s lots of low hanging fruit that could give way to new patterns, tailor-suited to your content.

I’m happy to announce my new book Mobile Faux Pas coming soon on A Book Apart! ↩

Alternate Realities

Fri, 13 May 2016 00:00:00 -0500

Over the past 9 months, I’ve been exploring what alternatives exist to the lackluster reality of Lists, Details, and Flows, a personal journey to cure my boredom. New frameworks, switching programming languages, and changing build tools every 6 weeks keeps me on my toes; but what I really seek are new ways to express content.

Here are a handful directions and technologies I’ve explored…

React?

I heard React was good and I was so impressed by Wes Bos’ React for Beginners course that I’ve started a few projects using it. There are a lot of strengths and weaknesses with React that would take me months to un-(web)pack, but what I really like is the “real-time’y’ness” of it all.

The React+Firebase combination that Wes demonstrates makes it incredibly easy to start daydreaming about real-time applications. The output is still Lists and Details, but real-time adds another dimension to designing and developing. If I had to pick a “future” or even “present future” of the web, I think the real-time aspect – regardless of how pedantic you want to be about frameworks vs vanilla JavaScript – is what the web ultimately wants to be.

React’s approach to state management and self-updating components are groundbreaking, but also a lotta action to get up and running. I’m optimistic about the future of web applications.

New data structures?

Spending a lot of time in document-based databases, I began to wonder if our typical key/value pair system of storing data (in objects and arrays) might be the cause of mundanity of lists and details. Maybe how we store data… affects how we collect and fetch data… affects how we present data.

GraphDBs are probably what I’m craving. If you’ve seen a graph visualization (e.g. a social graph), you’ll know they do a great job at illuminating relationships in content.

They can be beautiful, but there’s not a huge emotional response to a bunch of tethered nodes unless you’re a data scientist. That data can be used to render better, more relevant content but it would still likely exist in some kind of List view.

This path hasn’t taken me very far.

SVG animations?

While skimming graphic design books at a bookstore, my mind wondered as it usually does to how this applies to the web. Great print design has a few recurring themes (again, being over-reductive): imagery, playing inside fixed dimensions, with type set to masterfully interact with and balance the art.

As I thumbed through page after page of this, I realized the web has almost the opposite set of limitations. Images can be dynamic (gifs/video) or scripted, device dimensions are unknown, and type and imagery on the web have a clumsy relationship and often don’t couple well. Some of the structures that make for great graphic design almost make for bad web design.

After hearing great talks from Sarah Drasner, Brenna O’Brien, Val Head, and others about animation at CSSDevConf, I decided to try my hand at animating SVGs.

SVG animations are exciting! Frameworks like GSAP lower the bar and make complex animations easy to code, even for Math-ophobes. I’ve toyed with a few animations and I really see well crafted SVGs becoming the future of Art Direction on the web. Here’s an beautiful example from Dennis Gaebel:

See the Pen Underneath by GRAY GHOST (@grayghostvisuals) on CodePen.

Simple animations with a smidge of interactivity can add delight and I think this is something the web could be ~~good~~ better at when compared to its print-based predecessors. Using Saul Bass as an example, the web can be closer to designing opening credits than designing a movie poster.

Bots?

Bots and conversational UIs (aka, “No UIs”) are interesting territory. There is lots of “Bots are the new Apps” hype, so maybe removing the interface entirely can cure my interface boredom!

Fortunately I’ve been able to tinker with Slack bots for the past couple months and form quite a few opinions. While bots are a lot of fun to program, it seems they mostly just serve as a proxy for these Lists, Details, and Flows on the web.

A /command typically fetches data from a list or detail view, often just a single component from the more complex webview. A “conversation” with a bot is just a line-by-line abstraction of a “wizard” or “flow”, often more obtuse.

Integrations are powerful tools and I think bots have the ability to impart a powerful (magical) feeling when a somewhat complex task is automated through a very short command. Bots may be the worst way to order a pizza, but I think there’s a lot of mundane tasks waiting to be optimized in large companies. “Bots are the new Intranet” is maybe a more accurate statement.

Video games?

In my (limited) spare time I’ve started making a video game in Unity. This has been rewarding because it’s a very different kind of programming compared to the web. Objects can spawn objects that have the power to destroy each other! There’s nothing like that in web/app/product development.

TEH MONSTERS> THEY SPAWN pic.twitter.com/vGlyTIrETy
— Dave Rupert (@davatron5000) February 2, 2016

The “World Building” aspect of making video games is incredible. In a couple hours I can have a first-person camera walking around a rudimentary scene. I haven’t felt that thrill of creating in a long time.

I owe this blog more updates about the progress on this game. What I can say now is that it’s a Cartoon Horror Survival game with a focus on two player local co-op.

WebVR?

Like bots, VR is also super hyped up right now. After a few conversations with VR-believers, my curiosity was piqued. Along the lines of “world building”, VR and MR can blur the lines between reality and the impossible. One of my favorite VR demos is Timoni West showing Unity’s new VR Editor tool that allows you to make video games from within the video game you’re making! Inception!

I have the same reservations as everyone else; that isolating yourself in a facemask is just too weird for mass consumption. But when I see things like the whale in that video, my body involuntarily releases endorphins of wonder and I fall into VR’s trap.

WebVR is particularly interesting because no one has figured it out yet. How do we use the web in VR? What does my website look like in VR? Other than “Keep a high FPS so people don’t barf,” there aren’t really any rules. It might be the “junior varsity” version of VR, but I see a lot of creative potential for WebVR experiences in a Cardboard. Best of all, it’s not as complicated as you might imagine.

A-frame is an easy-to-use framework that allows you to create a VR environment, even in a CodePen. Then throw your phone into a (Free~$20) Cardboard viewer and marvel at the new universe you created with just a few lines of HTML. No Cardboard? That’s okay, you can make it fullscreen on your computer and walk around using the WASD keys. It’s like Progressive Enhancement for VR.

I have lots of thoughts on VR swirling around in my head, so if you want to drunkenly ramble about it in a bar let me know. “VR is the Future” is maybe overselling, but “VR is fun” is certain and my two year old son demands it whenever he comes into my office.

So…

That’s all I got. React is a lotta action, data structures aren’t that compelling, SVG Animations are a neat trick, Bots are okay, Video games are thrilling, and VR is fun. Again, maybe information wants to exist in Lists, Details, and Flows; and trying to imagine otherwise is futile but I’ve enjoyed my explorations thus far.

I’d love to hear what others are exploring in terms of creating different ways to experience content. Great examples, best practices, anything. I would love to see them and read about them.

Before I go, if you’re interested in more SVG Animation stuff (you should be), here’s an incomplete list of links and people to follow:

Lists, Details, and Flows

Tue, 19 Apr 2016 00:00:00 -0500

I’ve become a bit discontented. In a fit of base reductionism, my brain has begun boiling down digital design (apps/web/product/interface/etc, all the same thing) into to three types of designs: lists, details, and flows.

Lists are lists of things; collections that contain items. Often a homepage is a glorified list; a melting pot of lists even. “Indexes” or “Dashboards” we sometimes call them. A carousel is a horizontal list, shown one item at a time. Lists often take you to details.
Details zoom-in on a single item. These can be read-only or editable textboxes. Maybe there are some fancy charts and graphs. Details often contain more lists that link you to more details.
Flows are unique multiscreen bridges taking you from point A to point B. It could be a transactional checkout, where each screen has a digestible amount of editable details. Or it could be a wizard, a list of digestible content bites.

I’m sure there’s a Human Computer Interaction book I’ve never heard of that talks about this, but in my mind Apple’s iOS Human Interface Guidelines deserves a lot of credit for distilling these simple, modern digital design concepts. Not only did this document prepare us to design for the mobilpocalypse, but it illustrated these views very well and also shipped with prefab components to build them out.

Nothing is new under the sun however, WordPress has had this view structure with index and single views for quite some time. Rails too has scaffold index and show views. This pattern is possibly as old as software. Maybe as old as Kingdom-Phylum class ordering or books having a Table of Contents.

Maybe this is why websites all look the same? I don’t think sameness is inherently bad, it seems like we’re following the Web’s grain. Or, even more rudimentary, maybe this is the shape that information wants to exist.

Things don’t have to look the same either. There is a lot of freedom in these large buckets. Netflix is a list of movies and RetailMeNot is a list of coupons; they’re both lists yet they should probably look different. The design of the components should suit the content.

But if I’m honest with myself, reducing things down sort of ruined some of the magic of building websites. Once seen, it’s hard to un-see. In a lot of ways, the romance is gone now and I feel like I’m married to these three views over and over for the rest of my career.

Once that realization sets in, you spend the rest of your time wondering how we’ve collectively made everything so difficult if everything is always the same.

Jekyll on Bash on Ubuntu on Windows

Fri, 08 Apr 2016 00:00:00 -0500

UPDATE: Jekyll on Bash on Ubuntu on Windows is blocked by a libinotify file watching bug. This affects any file watching task (like Sass) that of Ruby and Node workflows depend on. If you want to do modern web development on Bash on Ubuntu on Windows, please vote it up in User Voice.

When Bash on Windows was announced at Build2016 this year I let out an audible “Holy Shit!” from the front row. This is a major turning point for Windows and also the #davegoeswindows experiment. Not having access to a Linux shell has been my biggest pain point, both from a software compatibility perspective and a creature of comfort standpoint.

With Bash landing in this week’s Insider Fast Track update, I installed Bash for Windows as quickly as possible. In order to test its mettle, I decided to pick one of the critical pieces of my workflow: Jekyll.

Install the Linux Subsystem

Update to Windows Insider Fast Track version >14316
Settings > Updates & Security > For developers > Check “Developer Mode”
Open “Windows Features” (from Cortana) > Check “Windows Subsystem for Linux (Beta)”. Restart.
Open Bash.exe for the first time to install Ubuntu.

This is where things get a little weird. You’re using Ubuntu on Windows, and that’s great, but there’s nothing there. It’s a complete ghost town and there aren’t really blog posts yet about getting your Bash on Windows environment up and running. So you have to install everything, even make and gcc, from scratch.

$ sudo -s
$ apt update
$ apt install make gcc

Install Ruby

I tried installing Ruby via the stock apt install ruby, but that only pulled an outdated ruby1.9.3. Jekyll needs at least 2.0 and the latest stable release is ruby2.3.0. I tried using rvm and rbenv but neither of those worked, each had their own different problem. I decided to use a Brightbox managed Ruby package for Ubuntu. No idea if this is secure or the Ubuntu way™, but the website seems clean and up-to-date, so…

$ apt-add-repository ppa:brightbox/ruby-ng
$ apt update
$ apt install ruby2.3 ruby2.3-dev ruby-switch

Everything should be installed and setup, but it feels good to verify. If it is messed up, ruby-switch is a nice little app that replaces both rvm and rbenv and in my limited experience, does a way better job.

$ ruby -v
$ ruby-switch --set ruby2.3

Install Jekyll

And now, for the Final Boss Battle. This couldn’t be easier. This is straight ruby’ing. No special hacks. Notice the /mnt/c/ in that directory path. That’s a mapping to your C:\ drive. From there, you have access to all your files just as God intended.

$ gem install jekyll
$ cd /mnt/c/Users/<your username>/Desktop
$ jekyll new myblog && cd myblog
$ jekyll serve -w

It’s working. And it’s FAST! Way faster than Ruby for Windows. Jekyll on Bash completed in 0.329s, Jekyll on PowerShell takes 0.364s but has a 5 second latency starting up. Jekyll on Bash was also 3x faster on --watch compilations as well.

From here I’ve been able to install Jekyll plugins I like to use like Jekyll::Compose and Jekyll::Archives and they’re working as expected.

Final Notes

I’m sold. I’m drinking the delicious Kool-Aid. I couldn’t be happier getting this portion of my workflow up and running on my PC. While the lack of documentation is daunting, the State of the Union is good and it has a wild west vibe to it. Next stop: Compiling and deploying this blog with rsync, then a full Rails application with Devise authentication.