Don’t Forget Design! (pt. 2)

In the last post we talked about a few different styles we can use to anchor our website, and ground it in a visual philosophy that makes the page as a whole make sense. Today we’re going to get a bit more specific about what sort of elements and design patterns we can use on our web page, not just the general feel and style we want them to have. These will be the things on out page that make it functional, and give the user an interface to change navigate the page and change the information she’s looking at.

Explicit Nav Menus

Here we see possibly the most traditional tool for users to move around a webpage – the navbar. In the above example, notice that we also have a sidebar. What a developer decides to put in these types of nav elements is up to him. Some devs like to have single link that the user is allowed to visit in one nav, and others like to spread them between a navbar and siderbar, and maybe throw a few others down in the footer for good measure. If or how you use it is up to you. Users are generally comfortable with this kind of navigation and know how to use it, but it has the side effect of making your site look busier and more cluttered.

Hidden Nav Menus

That last problem can be addressed by hidden, expandable, ‘hamburger’ menus. Especially since the rise of bootstrap, these types of menus have become extremely popular for their ability to provide the best of both worlds: an uncluttered page upon the user’s arrival, with the option to see much more if desired. For the most part, these menus have just opened into drop-down lists, but devs are quickly realizing that they can use those little hamburgers to prompt the appearance of any kind of menu they like.

I found the preceding bit of CSS and many others like it at this website.

Headers and Footers

Headers are pretty simple. You can throw a brand name in there, maybe something about the status of the user (logged in status, shopping cart status, etc) and a navbar. The footer can help to reduce clutter by providing a place to hide away all the stuff the average user doesn’t really need to be bothered with – copyright information, careers, about page, social media links, etc. The size of the footer will depend on the website, and the degree to which you want the page above the fold to be free of excess links.

Single page scroll

One way to make building a website much easier and still make it beautiful is to make is a Single Page Scroll site. Just by continuously scrolling down, users experience all of the content you want them to, in the order you want them to. This also opens the door for lots of nifty features, like navbars that stick to the top of the screen while you scroll, populated with links that auto-scroll you to the right place on the page. Scroll-sensitive animations can be included in the page that fire as you slide further down the page. Backgrounds can change as you scroll with the use of CSS sprites, and some of the most beautiful sites built today are built around this feature.

Transparency

A variation on Single Page Scroll, a Transparency results in text on a translucent background sliding over a stationary background as the user scrolls down. The effect can be striking as demonstrated if done correctly, and it can be employed in several different ways. Sometimes just a touch of a stationary background in an otherwise normal Single Page Scroll app can make the whole thing seem more professional. A touch of the technique can be seen here.

Conclusion

I’m having a great time, aren’t you!?! There are so many wonderful features to use in web design! Let’s take a break and we’ll come back for a few more to wrap up our design series in part 3!

 

Don’t forget design! (Pt. 1)

beAs a developer, it’s easy to get a little bit too sucked into backend stuff sometimes, to the point that when you have to build an interface, the result looks like a geocities site with random bootstrap buttons thrown in among a hodgepodge of weird colors and goofy-looking navigation. You know CSS really well, you know how to use a grid system… why does this look so terrible?

Oh yeah. You’ve forgotten design.

It’s easy to forget how hard design can without templates, and sometimes it’s hard for engineers to get started figuring out the ‘feel’ or ‘theme’ of something they would really just like to be functional.

But neglecting those aspects is really not an option. Even quite sparse sites like Reddit and Wikipedia make an effort to create consistent, cohesive interfaces with very deliberately chosen fonts and layouts that feel natural and professional. Even a site with important content and impressive back-end tech will fail if it looks like it was designed by a fourth-grader learning HTML for the first time.

So. Where do we start? In my opinion, the best way to divide up the huge topic of web design is into two subtopics – ‘Styles’ and ‘Features.’ When we talk about styles, we’re playing with very broad, high-level, design-y concepts, trends and movements that bleed out of web design into fields like print, graphic design, art and architecture. When we talk about Features, we’re talking about specific components used in web design. This week, let’s just take a look at three Styles and then next week we’ll check out three Features to get us started thinking in a more design-oriented way.

Styles

The Style of your website should be clear in your head before you touch a single CSS file or build anything stylistic at all. The thing that makes a website look professional is consistency of theme, and that will be determined by the style. Let’s take a look at a few styles:

International Typographic Style / Swiss Modern

By the way, this post will have a lot of pictures. Also, I recommend google imaging these style names to get an even better idea of them.

If you’ve ever spent a lot of time in Europe, this look will be familiar to you. Legibility, negative space, clean lines and lots of Helvetica. If you look at a signpost somewhere and see nothing but information, that’s Swiss Modern. Websites using this style will tend to use ‘hamburger’ menus to free up the page of any little bit of clutter, as in the following example.

In International Typographic, leaving things out is just as important as putting them in. Limited options and and the use of a single bold color (often red) are common in this style.

Retro

Let’s face it. We live in the future. And as cool as that is, it comes along with a nice dose of existential dread. I mean that site up there in the Swiss style has me thinking about my insignificance AND my clone-ability.

Oof. You know what I need? A nice, solid dose of nostalgia.

To be clear, the above isn’t technically a retro style, since it’s not trying to be old-fashioned on purpose, it’s ACTUALLY from the past. Nonetheless, it’s a good example of a design aesthetic that’s fun and pretty easy to implement in a page. You can find tons of components in photoshop or any other piece of graphic design software that will fit right into such a theme:

I should point out that this style is not appropriate for every situation – you don’t want the launch site for a new phone to be surrounded by imagery from the 50s, you would rather have such a product associated with the future. Where it does work well is when you’re selling a simple product, a link to the past is okay, and you’re able to have a bit of a sense of humor about yourself.

Grunge

The term ‘Grunge’ has its origins in the music of the 90s, but as a style it’s grown to refer to anything grimy and hardcore. It’s pretty straightforward, really – rebellion, chaos, dirt.

Websites in this style clearly identify as at least somewhat counter-cultural and may willingly sacrifice ease of use to achieve it.

The style can end up being much more difficult to work with than others, as there is often an attempt to get from the grid system. For example, slanted menus are common in the grunge style, an impossibility for normal HTML. This means that image mapping must be used for links, which breaks between different browsers. In short, it’s a risky style. But hey, isn’t that always the case with being on the fringe? Nonetheless, if you can pull it off, I think the results can be pretty cool.

So that’s it for styles. The vocabulary for talking about design varies a lot from person to person, so find a way to break it down that works for you. Next week we’ll talk about some of the actual features we can use in our website after we’ve chosen a style to go with.

Customized Styling for Devise Authentication Elements

As we all know, authentication can be tricky. Session persistence, encryption, third-party authentication, password resets…. there’s a lot to handle, and the stakes for screwing it up are high. Unless you consider yourself a specialist in authentication, it’s often best to eat a slice of humble pie and look at what the pros have made available to us.

When it comes to authenticating Ruby apps, that means using our old friend Devise. Devise gives options for nearly anything we could imagine having in a login/signup form.

Okay. We’ve installed the Devise gem and used rails g devise user to generate, behind the scenes, a database migration, model and series of views for users. We’ve migrated and we’ve thrown our Devise authenticate_user! method into a few places in our controller so that our users are asked to login if they haven’t yet. Cool! So for all intents and purposes now, we have authentication.

One problem, though : it looks all janky. The login form doesn’t fit into the style of the rest of the app.

So how do we style this thing? We can’t seem to find the file anywhere. Where are the view files for Devise elements?

They’re hidden. O.O

Devise keeps all of its generated files invisible by default. But we can expose them! Or, technically, we can copy them and make the copies the official one that gets used. It’s easy as pie.

rails g devise:views users

Boop! If we look in our views directory we’ll notice that Santa came early this year and he brought us a box full of CONTROL!

Over our Devise elements, I mean. If we open up the devise directory, we’ll see seven different directories. We’ll focus on three. sessions contains our login form, and registrations contains our new user form. Both of these forms are style-able with classes or ids just like anything we made ourselves. One thing that may bug you once you start playing with them is that changing the background of a form doesn’t change the form of everything that’s generated. First, move the heading inside the form element. Then take a look at the links that we pull in from the shared subfolder in the devise directory. This nifty file contains all the links to reset passwords, login with social media, etc. Just move the render up into the form element.

Boom! Everything’s contained in one unit now. Add a class or id to the form element and edit the main css file for your app to make them look how you like. I recommend giving the form width: 200px so that if you want to give it a custom background, it doesn’t look like it’s stretching across the page. If you’re feeling less custom-y and more boostrap-y, use the grid system to achieve the same effect!

 

Asynchronous Javascript for Beginners (pt. 3)

In this post we’ll discuss how asynchronous code has been dealt with up until the last few years. Namely, callbacks. Let’s start with the most basic example we have, a setTimeout call:

setTimeout(function(){ console.log(“Hello”); }, 3000);

As we’ve discussed, setTimeout is asynchronous. And so here it takes a callback function. What setTimeout does is calculate where in the process que it can slide that callback in that will occur AT LEAST three seconds later.

Now we have to take a quick break here because something is rearing its head already which, if we don’t take care of it, will lead to confusion. You might have heard that javascript is single-threaded. That only one process can be happening at any one time. Well if that’s the case, how can we have async at all? Isn’t that what asyc is, things happening at the same time? The answer is…well….. almost. But not quite! Your computer that you’re running right now is capable of truly running multiple processes at the same time, what we refer to as things running in parallel (as opposed to async). That’s how your machines can handle dozens of apps being open at the same time, all while handling tons of other processes behind the scenes that you never even see. Your computer is capable of running thousands of threads all at once! Pretty amazing, huh?

Well, don’t get too excited, because we don’t get to have those threads in our JS app. We get one. Javascript engines are single-threaded, meaning that we can only do one thing. At a time. So with this information on board, what is async in this new context?

It’s a trick. It’s a way of making your application SEEM likes it’s multi-threaded, even though it’s not. The reason we do this is for user experience.  If users see that SOMETHING is happening, it’s a lot easier to wait than if their screen just freezes for ten seconds, the result of allowing blocking processes in your app. So let’s get back to the main topic: callbacks and the problems they created. Let’s look at a simple AJAX request made with jQuery:

$.get( "ajax/test.html", function( data ) {

alert( "Load was performed." );

});

Pretty simple. Readable, easy to reason about. The problem is, what you wanted to do with a request usually wasn’t this easy. And when things got more complicated, you ended up with callback after callback, in a tangled maze that has come to be known as callback hell. Here is an example, taken from callbackhell.com :

fs.readdir(source, function (err, files) {
  if (err) {
    console.log('Error finding files: ' + err)
  } else {
    files.forEach(function (filename, fileIndex) {
      console.log(filename)
      gm(source + filename).size(function (err, values) {
        if (err) {
          console.log('Error identifying file size: ' + err)
        } else {
          console.log(filename + ' : ' + values)
          aspect = (values.width / values.height)
          widths.forEach(function (width, widthIndex) {
            height = Math.round(width / aspect)
            console.log('resizing ' + filename + 'to ' + height + 'x' + height)
            this.resize(width, height).write(dest + 'w' + width + '_' + filename, function(err) {
              if (err) console.log('Error writing file: ' + err)
            })
          }.bind(this))
        }
      })
    })
  }
})

The characteristic shape of this type of code came to be known as the pyramid of doom. However, even if the callbacks were extracted out into separate, external functions, we would find that it is still hard to reason about and that callback hell goes deeper than nesting and indentation. In the next post, we will explore those problems, and the solutions that were devised.

Asynchronous Javascript for Beginners (part 2)

Okay, so we’ve covered setTimeout( ). Let’s move on to AJAX.

AJAX (Asynchronous Javascript And XML) is where things get interesting. As you have have heard by now, the name AJAX is stupid. Most AJAX calls don’t actually use XML anymore, they use JSON. XML and JSON, by the way, are just different data exchange languages. Data exchange languages are different ways to format information and send it between different systems so that they can both understand it. So AJAX  is stupid, but to be fair though, we can all agree that it’s a way sexier name than AJAJ, so we’re sticking with it. I’ve heard the idea that you can think of the “X” as a variable for whatever data exchange language you want to use. I like that.

For now, we’re going to assume that we’re only using JSON. So AJAX now means ‘Asynchronous JS and JSON.’ Still not very descriptive. What does AJAX actually mean? Mainly, it just means getting JSON from another URL, or sending it. Boom. That’s mostly it, and I feel like that should have been conveyed somewhere in the acronym. It wasn’t, but it’s okay, we know now. We can take a deep breath and move on.

So the words in the AJAX acronym really just describe extra details about the main idea, mainly that this sending and receiving of JSON (or whatever) happens asynchronously. Take a look at this fiddle I found. It uses a JS method called fetch to do a bit of AJAX, namely a GET request. Change the code so that the JSON is logged to the console, then do like fifty console.log(“hello world)s or whatever you want right after the body of the fetch. As you can see, they all show up in the console first! Fetch is async, and as such it starts working, then stops for a while while the external server does its thing, letting the console.logs get to work until the fetch is ready to finish up and add its two cents to the console.

As you can now see, using AJAX means that async code become inevitable. In the next post, we will talk about the way async code has been dealt with traditionally, and the problems that arose as a result.

 

 

 

Asynchronous Javascript For Beginners (pt. 1)

Okay, no use beating around the bush. Asynchronous JS. What is is?

Probably the opposite of Synchronous JS, right? Let’s start there. Okay, what does ‘synchronous’ make you think of? Things happening at the same time. Synchronized swimmers. A team of bank robbers looking at their watches and yelling “Sync!” Stuff happening simultaneously. Which would make ‘async’ refer to things happening NOT at the same time. Right? Turns out, wrong.

Turns out, the definition is almost completely opposite. ‘Synchronous’ in programming doesn’t mean ‘at the same time’, but rather ‘one at a time, one after another.’ Synchronous programming just means that a series of events occur, and they occur in order:

1. Thing 1 happens
2. Thing 2 happens
3. Thing 3 happens
4. Thing 4 happens

Okay. So we’ve defined synchronous as one after another. Asynchronous code, on the other hand, will refer to code that starts running, and then for some reason has to stop in the middle, at which point later processes just start running AS IF that earlier thing was already done doing its thing. THEN, once that earlier process is ready to finish what it was doing, it picks up where it left off and finishes up.

1. Thing 1 happens
2. Thing 2 starts doing its thing and then is all like “Oh damn I actually can’t finish this right now, you guys go on without me”
3. Thing 3 happens
4. Thing 4 happens
5. Thing 2 is like “Okay whew, I’m ready now” and finishes doing its thing.

So that’s Asynchronous Javascript. But what kind of things could Thing 2 be, that it needs to take so long to finish? This obviously isn’t just a list of console.logs, one after another. Here’s a list of things that make your code async, lifted from Byte Archer’s terrific post:

• timer functions setTimeout, setInterval
• special functions nextTick, setImmediate
• listening to network, querying a database
• reading or writing, generally I/O from a resource
• subscribing to an event

If you don’t want to go to far down the rabbit hole right now, just remember that the following two things are asynchronous: setTimeout( ) and AJAX.

If you play around a bit with setTimeOut( ) it won’t take long for you to see this in action. If you do a setTimeOut( ) with a console.log in it, followed by several other console.logs, you’ll see that the later ones don’t wait up for the async one, they just happen first.

We’ll pick up with Ajax in part 2.

How We Got To Redux (for people who blinked)

As we scramble to assemble our stacks of packages, routers, stylers, store persisters and the like, it’s worth it to take a moment  to breathe, look around and get a bit of perspective on what exactly it is that we’re doing and why we’re doing it. I’ll let you get back to trying to make thunk work in a second, but for right now we’re gonna look back, waaaaay back to the dark ages of 1994.

The darkness was rend in twain by the publishing of the book Design Patterns: Elements of Reusable Object-Oriented Software. The work was one of the first comprehensive collections of the development patterns  that programmers had discovered and re-discovered over the preceding decades. Among the patterns described was one called The Observer Pattern. The gist of it is that you have an object called the observer that contains all of your state. An app’s ‘state’ is just its memory of any events that have occurred or user interactions that have taken place. In many patterns, state ends up scattered all over the app, in a million different variables. In the Observer Pattern, however, your state is contained in one big object. It has listeners on it that connect to all the dynamic parts of your app. If a certain part of your state changes, so does the element connected by the listener.

Facebook first made React public in 2011 and open-sourced it in 2013. It was created by Jordan Walke. Despite the way we think of it now, React wasn’t just a vehicle to give us all Redux. At an F8 session in 2014, Tom Occhino, the Engineering Manager at Facebook, gave a talk where he outlined problems Facebook had encountered with the standard MVC application architecture, and announced something called Flux.

Flux was a design pattern, and architecture. It was not an actual product that Facebook had built, it was simply a way of doing things that had allowed Facebook to dramatically cut down on bugs and made their codebase easier to work on without fear of breaking things. As people outside Facebook began wanting to write in Flux as well, demand grew for a framework, an implementation of the Flux pattern. Facebook released a dispatch method and left it at that. Fluxify was written, as was Reflux.

Dan Abramov, while trying to work in Flux was growing frustrated. Not only did the existing implementations not suit his needs, he wanted hot reloading. On top of that, he had realized that using pure object actions with reducers on a pure object store would enable time-travel debugging, replaying an app’s change in state over time. On May 29 2015, he tweeted “Oh no am I really writing my own Flux library” and Redux, from “Reducer” and “Flux” was born.

In 2015, Abramov gave a presentation at React Europe that showed a workflow with hot reloading and time travel debugging, made possible with Redux. Since then, the React-Redux ecosystem has only grown, with packages for routing, styling, and much more becoming part of the React developer’s toolkit.