I had a reader write in with an interesting question:
When one has multi-level navigation, do you think it crucial to have an actual page for the top-level item? For instance, About > Company, Founder, History.
There isn't really anything worth putting on the About page that wouldn't be on the three sub-pages. In the nav, should About just redirect to Company? Should there not be a Company page and its content be moved to About?
Any best practices you've found over the years?
I'm picturing this kind of thing:
And the issue is that "About" by itself isn't particularly useful. But it is useful as a grouping for the sub pages.
I would think the "About" link should be functional no matter what. It's just a matter of what to do with it.
Just make an intermediary page
Have the parent link:
http://website.com/about/
And the subpages:
http://website.com/about/company/
http://website.com/about/founder/
http://website.com/about/history/
They said there isn't anything "worth" putting on the About page, but that's just a matter of content wrangling. You could write some new content introducing the other content there. Or show some elaborate breadcrumbs encouraging them to go deeper. Or show some images or snippets from the sub pages. I'm sure you can think of something.
Redirect the intermediary page
Have:
http://website.com/about/
Redirect to:
http://website.com/about/company/
That way the URL stays nice and hierarchical and gives you the opportunity to create an About page alone in the future.
It might feel a little unexpected though, so it might be nice to offer some kind of sideways navigation. Seems like the kind of thing that could be tabbed:
Skip the hierarchy
If there is really no point to having a parent page, maybe the URL's should be clear that there isn't one.
http://website.com/about-company/
http://website.com/about-founder/
http://website.com/about-history/
And then use the redirect for the top-level navigation option.
Put them all on one page
Is there any value in separating them? You could go with a tabs design pattern with all on-page content. Or just make a long page, the web can handle it =).
The URL's could use hashes to go to the relevant place (or tab):
http://website.com/about/#company
http://website.com/about/#founder
http://website.com/about/#history
Best Practices
I'm not sure any one of these is any better than the other. I think the best practices here come in the form of don'ts:
Don't do it one way then change it to another next month. Cool URL's don't change.
Don't make your dropdown 100% reliant on JavaScript.
Don't make the About link not-actually-a-link just because you don't have this figure out yet. Link it to something or redirect it.
Have you all gone through this kind of thing before?
I had a reader write in with an interesting question:
When one has multi-level navigation, do you think it crucial to have an actual page for the top-level item? For instance, About > Company, Founder, History.
There isn't really anything worth putting on the About page that wouldn't be on the three sub-pages. In the nav, should About just redirect to Company? Should there not be a Company page and its content be moved to About?
Any best practices you've found over the years?
I'm picturing this kind of thing:
And the issue is that "About" by itself isn't particularly useful. But it is useful as a grouping for the sub pages.
I would think the "About" link should be functional no matter what. It's just a matter of what to do with it.
Just make an intermediary page
Have the parent link:
http://website.com/about/
And the subpages:
http://website.com/about/company/
http://website.com/about/founder/
http://website.com/about/history/
They said there isn't anything "worth" putting on the About page, but that's just a matter of content wrangling. You could write some new content introducing the other content there. Or show some elaborate breadcrumbs encouraging them to go deeper. Or show some images or snippets from the sub pages. I'm sure you can think of something.
Redirect the intermediary page
Have:
http://website.com/about/
Redirect to:
http://website.com/about/company/
That way the URL stays nice and hierarchical and gives you the opportunity to create an About page alone in the future.
It might feel a little unexpected though, so it might be nice to offer some kind of sideways navigation. Seems like the kind of thing that could be tabbed:
Skip the hierarchy
If there is really no point to having a parent page, maybe the URL's should be clear that there isn't one.
http://website.com/about-company/
http://website.com/about-founder/
http://website.com/about-history/
And then use the redirect for the top-level navigation option.
Put them all on one page
Is there any value in separating them? You could go with a tabs design pattern with all on-page content. Or just make a long page, the web can handle it =).
The URL's could use hashes to go to the relevant place (or tab):
http://website.com/about/#company
http://website.com/about/#founder
http://website.com/about/#history
Best Practices
I'm not sure any one of these is any better than the other. I think the best practices here come in the form of don'ts:
Don't do it one way then change it to another next month. Cool URL's don't change.
Don't make your dropdown 100% reliant on JavaScript.
Don't make the About link not-actually-a-link just because you don't have this figure out yet. Link it to something or redirect it.
Have you all gone through this kind of thing before?
The following is a guest post by Brin Wilson of WinningWP. Brin wrote to me wanting to do a little advertising for his site. I of course would happily accept that, but even better, since Brin is a tech writer anyway, why not write a guest post. That's always a win-win, and since he had a good idea anyway... take it away Brin!
If you're reading this, my guess is you're someone who cares about user experience. Like me, I'll bet you've probably spent countless hours trying to perfect every last detail of your site: from ensuring everything looks as it should on numerous different devices to creating either an entertaining and/or a helpful 404 page! But have you ever considered what happens when people search your site using the search functionality you've provided (i.e. usually a simple search box located somewhere near top of the page) but inadvertently hit enter without having actually typed anything?
Looking around the web, there appears to be no real consensus on what should happen in this particular edge-case scenario. Indeed, even the vast majority of industry-leading web design blogs seem to give no real consensus on what should or shouldn't happen!
In these cases it's likely a WordPress theme that is 1) using default WordPress search and 2) missing a search.php template file (or the template is essentially the same as the homepage). So, the default homepage will be loaded with no search filter, meaning no filter is applied and you'll see whatever is normally on that page. It's not very clear what is going on.
The search box simply does nothing and/or closes itself.
Nothing Searched For / Nothing Found
Familiar examples include this very site, i.e. CSS-Tricks and, in fact, currently my own site WinningWP.
A default result appears quoting whatever the user has searched for (in this case nothing), and no results are shown. Kind of the opposite of the first examples where because there is no search filter, everything is found. But you're also on a clear search page so some action has happened.
So what should be made to happen? Well, using the attribute 'required' would arguably go along way towards improving the user-experience in browsers that support this part of HTML5.
<input required type="search" name="q" id="q">
Thereby simply stopping the users with more-modern browsers from even being able to perform a blank search in the first place (as exemplified by the empty-search-box-behavior over on Speckboy Design Magazine). Here's a complete form example:
Editors note: I updated the search form here to use required because it seems like an easy/obvious improvement.
But what about non-supporting browsers? Is this good enough? And more to the point: can we do better?
Personally, I'm of the opinion that these types of empty search-box searches could perhaps best serve the user by being made to return a result that tells the user they've conducted a search but somehow or other managed to leave the search box empty. Perhaps in a kind of humorous-404-page style. Although, that said, I realize this might be going overboard – and would probably be a bit inappropriate for some websites.
Perhaps one of the nicest user-experiences (suggested by Chris after seeing the first draft of this post) could be provided by taking the user to a really well-designed full-page search experience: perhaps with the addition of some suggested popular search terms.
Or maybe the blank search is just too much of an edge case to worry about – especially on sites with relatively low traffic.
Any other suggestions for what best to return when a user leaves the search box empty? Is there some chance the user just clicked search on accident or had another assumption about what it would do? Thoughts?
As I type this, Dave Rupert and I have recorded 137 episodes of ShopTalk. ShopTalk is primarily a question-and-answer style show. Dave's early idea was to have it be loosely modeled after the most popular NPR show of all time, Car Talk, which is mostly Q&A. We have guests, and we talk a bit about the guest so people have a sense of who they are, but it's not exactly an interview show.
We solicit people's questions on ShopTalk. Again as I type this, we're closing in on 2,000 questions people have sent in. I've read every single one of them and there are definitely some repeating themes. I think it's an interesting look at the vibe of the industry.
The "Should I go to college?" Question
Sometimes this comes from high school age people who are curious if it's "worth it" to go to college, or that worry that college won't teach them current technology. Like this one from Ledian Morales:
I work as web developer at a well known web company. I have learned a lot from the people here. They hired me straight out of high school, so I was never able to go to a college or a university. They taught me everything I know. I make good money. But I want to go bigger. I want to learn more.
Should I go to a university?
Based on the research I have been doing, a lot of people are saying it is not worth it. The information they teach is outdated. You can learn more with Google Search. Is it worth it?
Or from people already in the workforce interested in a career shift. Like this one from Marc Levine:
I am 39 years old. My wife and I have two young children. I am a corporate trainer. I want to change my career and become a web developer. On nights and weekends for the last 6+ months, I have been learning HTML, CSS, JavaScript, jQuery and Ruby through Codeacademy, CSS-Tricks, Lynda.com, and other sites. I have learned a lot, but I still feel like a beginner.
I have been accepted to a graduate certificate program in Web Design & Development at a local university. It is the only program in the area that caters to working adults. After learning more about the program, I am skeptical, because it seems like it is going to be covering somewhat older content, maybe not as much hands on, paper writing, traditional academia, etc.
Is it feasible that I can learn everything on my own, basically through internet resources? If yes, how would I do that? What are some specific things that you all would recommend? I need to position myself so that I am a viable and hirable job applicant. Time is of the essence - I'm not getting any younger.
I think this is such a common question because it's a huge life decision (lots of time, lots of money) and the results are unclear. College isn't a car wash. When you go through a car wash, your car is clean at the end. When you go through college, you are ???? at the end. Smarter? More employable? Maybe. Broke? Probably. Because so many people do it and the results are all over the place, it's a tough call.
Based on my personal experience: go. Learning what a for-loop is isn't what you get out of college. Hopefully, a huge well-rounded chunk of knowledge and experience is what you get that benefits you forever is what you get out of college.
Should they continue their studies or jump straight into the labour market? I usually tell them that ability trumps education and I don’t put much faith on the current raft of tech degrees. So I'd prefer to see three years of experience than three years of study.
That being said, I'll also point out that University is about much more than just acquiring a skill. It's a formative experience that will shape your attitudes for the rest of your life. It's also a huge amount of fun, or at least it was in my day.
The "fun" thing might not be an important factor when you're decided to go back later in life with more at stake. Not to be overlooked is the rise of the "Code School" - shorter, more focused, but also expensive and often un-accredited schools that offer to blast you with knowledge and get you changing careers in a hurry. I've seen success happen through them, but surely the results vary.
We've talked about this subject on the show several times. To hear more, check these TimeJump links:
The tide of front end development moved lots and lots of front end developers toward developing locally over the last several years. Technologies like preprocessors and version control require that, and front end developers are firmly on-board with that. But WordPress is huge, and WordPress is a back-end technology that requires back-end things to work. MySQL, PHP, Apache, a local domain. All the sudden tooling is a big part of the front end developer job, and the shoe fits.
But the tooling for MySQL hasn't quite caught up. It still hasn't, if you ask me. It's reasonable to want to work on near-exact replica of a live site on local, then push up changes. And so much of what WordPress does and shows is in that database.
Version control doesn't help with the database. Connecting a local site to a live database is risky. Exporting/importing tools directly in WordPress aren't great. Manually dumping the database from the command line, downloading it, and running the SQL locally is tedious and inefficient. No wonder it was such a hot topic.
The answer is essentially, use WP Migrate DB Pro. Full disclosure: they have sponsored the show. But it's the only option out there that I've found that actually does the job. It costs money (good, because that means they run a business on keeping it working well).
I think enough people are becoming aware of this that we don't get the question nearly as much as we have in the past.
The "How do you make a podcast" Question
We have a podcast. Lots of people want to start a podcast, like Nick Santini:
I was wondering if you could tell us a little bit about how you about the recording process for your podcasts and how you incorporate it into the site?
Dave and I aren't in the same room (or even state) usually, so we need to talk to each other. Plus the guest could be anywhere in the world. Even though neither of us, nor our typical guest, is a big Skype user, everyone tends to have an account, know how to use it, and it generally works. We start up a call there, get everyone on the same call, and chat for a while as we set up.
Skype can be choppy sometimes though, so even if everyone follows all our advice the call might have some rough spots that wouldn't make for a good recorded podcast. For that reason, we have each guest record their audio locally. It's really easy (on a Mac, at least, which is all I know), because you can do it directly through Quicktime Player. Everybody records their own audio locally, which will be of good quality without rough spots.
We have a podcast editor, Aaron Dowd, who stitches them all together and makes the final MP3 file that goes out.
On the ShopTalk website, we use the podPress plugin to generate the iTunes compatible feed and all that. For CodePen radio, I use the Blubrry one. On CSS-Tricks, I hand-created (and later used WordPress templating) to generate the RSS feed that iTunes uses. It's just a special format.
You'll need to host the MP3 file somewhere. I use Amazon S3 on CSS-Tricks and CodePen, which can be fine for that. Using your own web hosting probably isn't a great idea as it isn't really priced for media hosting bandwidth. On ShopTalk we use BuzzSprout, which gives us analytics, which is great.
For the LIVE part of ShopTalk, I'm afraid I'm not the expert. Maybe someday Dave will post a thing on how he manages it all. I know that he brings in a second computer ("The Intern") into the Skype call. Then somehow that computer passes the audio from the combined call over to (Wavestreaming? SHOUTcast?) which then (I think?) gives us a URL that Dave plugins into an MP3 player baked into our Live page. Somehow an iPad is plugged into the call too, which pipes in the sound effects.
There is literally so much 'stuff' to learn in this industry, it's often overwhelming! Do I push my knowledge of JavaScript and learn the ins-and-outs of different design patterns? Do I learn something new like Swift? Do I learn how to animate element on a page with canvas and CSS3 animations? Do I go learn Node.js and its associated frameworks?
When we're feeling in a direct-answer mood, the answer is usually: learn JavaScript. It really seems like that's a solid bet for a good long-lasting career right now. Not to mention the programming fundamentals that will stay with you forever.
But really: just build websites. There is nothing more motivational, practical, and applicable to real work than actually building actual websites. The the site you are working on guide what you learn next. Because you need it. Because it will enable the site to do something, or do it faster, or better. Learning from a book or course or classroom is great, but no substitute for the real thing, and they don't have to be mutually exclusive.
The "Should I change jobs?" Question
This is a little bit like the university question in that it involves a huge life choice where the outcome is uncertain. Will you make more money? How much does that money matter? Isn't happiness more important? How do you even know if you'll be happy at a new job? How does your family life factor in? Thats just the tip of the iceberg.
Here's an example from Daniel Grigorov:
I recently started working in a small web design company. I am doing the websites design and the coding as well. I really like doing both these things, but maybe after a couple of years I would like to move out and find a job at a bigger company.
Is it possible to find job into a big web design company and do both the web designer's and web front end's jobs simultaneously or should I pick one of those jobs only and put all my efforts into mastering it?
There is always stuff written between the lines. "A bigger company" I feel likely implies that he wants to make more money. Rarely do people say "I wish I worked in a cubicle with more middle management where I had less influence on the company!"
Or perhaps he is thinking of a higher level of prestige at some "tech giant" and worries that the jack-of-all-trades situation he has going on now will limit his ability to land a job like that. It might, sadly. If you put in all your time into design, you'd certainly be a better (and more impressive) designer. Likewise if you spent all your time in JavaScript, you'd be able to ace technical interviews easier. I don't hear about companies hiring generalists very often (which I personally think is sad).
But most importantly, it's clear Daniel is passionate about this work and does the work. That alone makes me pretty darn sure he'll do great.
We'll have to do this again sometime when new questions emerge that signal a tide shift in the front end world. I hope to someday be pondering "Should I go to Mars to learn SpaceNode? Or should should I stay here on Earth and focus on my CSS6 skills?"
Responsive Images: If you’re just changing resolutions, use srcset.
If you're implementing responsive images (different images in HTML for different situations) and all you are doing is switching between different versions of the same image (the vast majority of usage), all you need is the srcset attribute on the <img>. Gaze upon this easy syntax:
It's not just the syntax that is easy, it does a better job than <picture> with <source>s with explicit media attributes (we'll cover why in a moment). Plus it has the opportunity to be much better in the future with browser settings and browser improvements.
I've screencasted about this before, but it clicked better watching Mat Marquis's talk at An Event Apart Austin and with Jason Grigsby's post. I'm writing about it again here because I think it's important for all of us to understand.
With srcset, the browser does the work of figuring out which image is best
In the simple example above, all we're doing is telling the browser about some images that we have available and what size they are. The browser then does all the work figuring out which one will be best.
Mat Marquis demonstrated this by showing how the browser approaches it with math. Say you're on a device with a screen width of 320px and is a 1x (non-retina) display. and the images you have are small.jpg (500px wide), medium.jpg (1000px wide), and large.jpg (2000px wide).
The browser goes:
Lemme do some quick math that nobody cares about except me.
OK, so since I'm a 1x display, 1.5625 is the closest to what I need. It's a little high, but it's the best option compared to those other that are way too high.
Now another browser visits the site. It's also a 320px display but it's a retina (2x) display. That browser does the same math, only then goes:
OK, so since I'm a 2x display, I'm going to throw out that 1.5625 image because it's too low for me and might look bad. I'm going to use the 3.125 image.
See how that's already useful? You're letting the browser do the work of figuring out what's best for it rather than you trying to figure it out.
The browser is going to get smarter still
Remember there is already benefit to using srcset this way, but it's going to get better yet. Think of srcset as suggestions or just extra information to help a browser decide. Ultimately it can do what it thinks is right. That means:
A browser could offer user preferences regarding images
A browser could start factoring in bandwidth
Yes, theoretical, but likely.
And if you go down the <picture> with explicit sources, the browser has to do exactly what you say and not make choices for itself. Now, <picture> can be set up such that it does exactly what srcset it going to do right now, it's just a lot more verbose and doesn't leave room for improvement.
Also, sizes
We didn't talk about the sizes attribute at all here, on purpose. It's actually not that bad to just leave it off. In that case, it assumes sizes="100vw", which is saying:
I assume that when you use an image, it's going to be the entire width of the viewport.
That's usually not an awful assumption to make.
If you want, you can get all kinds of specific about it. You can use sizes to match your CSS layout exactly and tell the browser exactly how big that image is going to be on every screen size, matching how your breakpoints work in your design. That can get a little complicated and honestly it might be a little dangerous because you're putting CSS stuff in markup and you know how that goes. Eric Portis just wrote about this. Ideally it can be automated or injected server-side.
I also think kind of "generic" sizes attributes might be useful. On a kinda generic blog-ish site, maybe something like this is smart within content:
sizes="(min-width: 800px) 50vw, 100vw"
Meaning: "If the browser window is wider than 800px, this image is probably going to be displayed about half the size of that. If it's smaller, it'll probably be full-width."
Why talk about this?
Again: the vast majority of responsive images use isn't "art direction" based. Art direction is a fancy use case, and please do it to your heart's content. <picture> is great at that.
Most responsive images uses will be: "I have multiple versions of this graphic. Here they are, use the right one."
This is a very confusing subject. It needs to get thought about and written about so it can shake out and become a more ingrained part of our collective front end developer consciousness.
Tim Evko created a WordPress plugin for responsive images. It leverages WordPress's ability to make smaller versions of images. Then you click the image you want, and it ultimately outputs the responsive images code needed for it. At the moment, it uses <picture>. That's because is up in the collective front end developer consciousness in a way stronger way that srcset. Tim is trying to understand all this so he can figure out if and how to change that plugin.
@Tevko@brad_frost srcset/sizes = information to help browser decide which best. Picture w media attrs = explicit DO THIS ONLY
I've had some disparate thoughts regarding pagination lately, so I thought I'd attempt to organize them in a post. That's how blogging works right?
Consistent Positioning
If there is any way to make sure your pagination buttons don't move, do it. It's such a nice experience to be able to just click-click-click (or tap-tap-tap) and the same thing happens each time. And when you get to the end, a subsequent click doesn't all the sudden to something different (because you're now clicking on a different button, or nothing).
If one button depends on the other for positioning, perhaps you could disable one and like opacity: 0.5; it to indicate its disabled-ness or even visibility: hidden; to hide it but still have it in the document flow.
Vertical positioning is important too. It's nice if the pagination buttons don't jump around based on the height of arbitrary content. If that's unavoidable, because, say, they are positioned below the bottom of arbitrary content, perhaps they buttons could be on top instead. Or in addition to, which is nice for content the requires scrolling.
Of course all situations are different, but perhaps even position: fixed; for some pagination elements would be useful to ensure those positions remain stable.
Text or no?
What is the pagination pagination past? (say that 10 times fast). The text in the buttons could help make that clear.
"Older"
"Newer"
"Next page"
"Previous page"
Mayyyybe. But what about:
"Less Relevant"
"More Relevant"
"Less Popular Content"
"More Popular Content"
While that may indeed be what the pagination is doing, that's kind of a bummer to say. I would tend to say: if the reason for pagination is fairly obvious or non-imperative, just use arrows.
Here on Dribbble, text is unnecessary. There is a web affordance that clicking that arrow is going to show more content.
One caveat to not displaying text is directionality. Will people enter your site on a page in which it is possible to paginate in either direction? If that's the case text might be appropriate, to orient people who didn't get the benefit of starting at a page in which you could only paginate in one direction.
Directionality
Speaking of arrows, which direction is most appropriate? I tend to find that most pagination begins with an arrow pointing to the right. (ala Google Search Results) I've heard this hotly debated with good points on both sides though. If you think of a timeline, that's almost always left-to-right and so paginating through time you'd think the arrow would point left if viewing the most recent content. But left arrows are associated with the back button, which is highly used and generally understood by users to mean going back to a previously visited area.
If there is a good chance a user might enter your site on a page in which you can paginate in either direction, I'd error on clarity and label the buttons.
URL Structure
Pagination often happens with URL's that go like:
website.com/page/1/
website.com/page/2/
That's not awful - at least it's clean. The trouble is that the URL doesn't contain any information about what is being paginated. But worse, the content on those pages can change. What is on page 1 today might be on page 3 tomorrow. That's super common in date-based pagination.
Us web people are always really concerned with keeping URL's alive and hate it when URL's break. But isn't a URL that shows totally different content than when it was last referenced broken? It depends, and it might not be a fixable problem depending on the type of pagination being done. But it probably is fixable for date-based pagination. The current design of blogs on the Gawker network has pagination buttons that get you to URL's like:
lifehacker.com/?startTime=1411848000454
lifehacker.com/?startTime=1411749900413
Those URL's are more likely to have the same content on them over time, since it references content based on the publication time.
Depending on the publication frequency of your site, perhaps your pagination buttons could be months, weeks, or days, rather than arbitrary pages. Paginating back from a homepage of content might be like:
website.com/blog/
website.com/blog/2014/09/
website.com/blog/2014/08/
Then those URL's would always have the same content on them over time.
Even if you prefer using arbitrary chronological integer based pagination, wouldn't it make sense to reverse the numbers? Instead of 1, 2, 3 going back in time, have the numbers start at the highest for how much content you have.
website.com/blog/
website.com/blog/page/523/
website.com/blog/page/522/
I wonder why it's seemingly never done that way. Perhaps it involves the stress of count queries on older database systems?
Indication of how many, or no?
Speaking of count queries, should you indicate how much content there is to paginate through? In order to do that, you need to know how much there is, which involves some kind of count at some point.
<- Page 1 of 302 ->
Is that useful. I might argue it is if the number could reasonably be useful. Either because you could look through it all, or because it gives you a sense of the breadth of your search, or because you might need that for use in an API, or something like that. It's probably not particularly useful somewhere like Google where it tells you it found eleventy-gillion results and it's really just showing off.
Other than just how many, should you be able to jump along further in the pagination?
[<-] [1] ... [5] [6] [7] ... [302] [->]
I dunno. I've always kinda baulked at pagination like this because it seems overly complex and marginally useful. Not to mention harder to honor consistent positioning. It does offer a way to jump to the start or end of pagination, which I could see being useful. It's just the longer versions that allow me to jump ahead like 4 pages (but not 6!) seem like they let a programmer little too close to the front end =).
Ajax
Pagination is the perfect kind of thing to do without a full page refresh, because it's highly likely the only thing changing on the page is the stuff being paginated. But this introduces some new complexities:
Do you append new content to the bottom of the current content area?
Is there a risk of so much content being added that the DOM weight slows down the page? Can you remove content at any point?
Do you replace all the content with new content?
If you do, should you scroll to the top of that new content? How do you do that across browsers?
Are you "losing" pageviews this way? Does that affect your business? Can you track this or do the same things that pageviews would have done for you anyway (e.g. rotate ads)?
Do you refer to the pagination differently, like "Load More Content"? Or is that inside baseball that only web workers care about?
Do you offer pagination in both directions this way?
Do the URL's change?
Can it be approached with progressive enhancement so pagination always works no matter what?
WordPress.com themes are leaning this way. I checked out a number of themes and they tend to have an "Older Posts" button that brings in new stuff Ajax style.
In this particular "Eighties" theme, there is no pagination at all without JavaScript. You can get to the content because there is links to the different months of content in the footer. Seems a little half-baked of an approach to me.
Consistency
Whatever you choose, be consistent about it across your entire site.
Lawd knows I need to implement some of these things of this across my sites.
It's not really a "game" - but more like a set of rules by mathematician John Horton Conway. Imagine a grid of cells, like a spreadsheet or a <table>. Each cell is either alive or dead. "Rounds" pass one by one. In each round, there are rules on whether a live cell should continue to live or die, and if a dead cell should continue to be dead or become alive.
The Rules
It's sort of meant to replicate a real life environment. Cells can die either by underpopulation or overpopulation, and only live in perfect situations. The rules are pretty simple:
Alive cell - Fewer than 2 alive neighbours - dies (underpopulation).
Alive cell - 2 or 3 neighbours - continues to live (perfect situation).
Alive cell - More than 3 alive neighbours - dies (overpopulation).
Dead cell - Exactly three alive neighbours - becomes alive (reproduction).
Why are you talking about this?
I feel wicked nostalgic about it. A visual version of The Game of Life was the first programming project I ever did in High School. Or if not the first, the first one where I had an "Ah ha!" moment and realized programming and design could be super fun and interesting.
Give the problem to any programmer and they will likely solve it in a slightly different way.
What language should it be written in?
How do we architect it cleanly?
How can we make it computationally fast?
How big can we make it before it slows down?
How do we best store the data and states?
How are edges handled?
Give the problem to any designer and the results will look different.
What colors make sense?
Should we have different colors for states beyond alive and dead?
How big should the cells be to be interesting?
How fast should the rounds be to be interesting without being overwhelming?
Can you interact with it?
Can you go forward and backward in time?
How do you turn on and off cells? Clicking? Dragging? Randomization?
I also bring this up because I remember trying to make a demo a few years ago that was so awful that I'm jealous of all the cool ones. I basically used jQuery to query the DOM for neighbors of every single cell and it was so inefficient I probably should have been beaten with an antenna.
Examples
My first version was in Turbo Pascal on an old Apple. It brings me great pleasure to know that this little visual mathematical exercise is alive and well today, and people are using a tool I built to make versions. Even amongst demos that use the same technology, the approach can be different! I also have a collection.
These are just front-end examples, but you can easily find examples in any language. Check out Golly for native app versions and the Wikipedia page for more information. One particularly interesting thing about The Game of Life is that all kinds of weird structures are possible that kind of "create life" or sustain it in weird ways.
One thing I've never seen is a Pure CSS version. Is it even possible? It would be wicked complicated with weird positioning and complex selectors. But they say Sass is "Turing Complete" so that means it's possible right? Or are other limitations at play there?
I'd be interested to see any more weird front end examples of The Game of Life. Or any stories you have about it from your past =).
