Collapsing Content

The cornerstone of responsive design is collapsing (and expanding) content to fit on differently sized screens. But what’s the best way to do it? There are many ways to accomplish a responsive design. If you use front-end frameworks like Bootstrap or Materialize.css, responsive design is usually built right in. But, if you don’t use frameworks, it’s easy to forget about what looks good across platforms, and it gets hard to test for it.

It’s important to design responsively.

A lot of internet traffic (like, 56%) comes from mobile platforms. So, engaging with your audience means implementing a responsive design. Not only does responsive design ensure that your mobile user base is taken care of, but it also makes your users with large screens feel at home. And, as screens are becoming bigger, higher in pixel density, and easier to attain, it’s becoming just as important to serve those users.

Methods

There are a lot of ways to implement a responsive design. I’ve already mentioned one: using a front-end framework. Bootstrap, Materialize.css, and Foundation all do a wonderful job implementing responsive design out-of-the-box. But, if you’re like me, you like to eliminate learning whatever framework is popular and hand-coding your sites, or, maybe, using your own, custom built set of modules, or even your own framework.

Media Queries

Media Queries are the groundwork of a responsive design. In CSS, they can be used to change the styles of elements depending on screen size, orientation, and media type. Here are a few standard media queries that I use.

@media screen and (max-width: 575px) {
  //desktop, browser sized to < 575px
}

@media print {
  //printed version of a webpage
}

@media screen and (min-width: 1400px) {
  //large desktop
}

@media screen
  and (max-width: 1400px)
  and (min-width: 575px) {
    //medium desktop, browser sized 575px to 1400px
  }

Inside the media query blocks, your declarations change the behavior of the selected elements. If I have an image that is half width on a large desktop that I want full width on a smaller screen, I may have a media query that looks something like this:

img {
  width: 50%;
  float: left;
}
@media screen and (max-width: 575px) {
  img {
    width: 100%;
    float: none;
  }
}

That’s all fine and dandy, but it’s definitely not all that responsive web design is. There are a lot of other tools in this bag.

Percentages over pixels

I’m a strong proponent of using percentage values over absolute values, except in very rare cases, like declaring border width. And using percentages isn’t difficult either. Relative sizes can be calculated easily:
target ÷ context = result
Proportional sizing encourages responsive design. Let’s dive in a little bit here. Say you’ve got a layout, a .psd from your designer, that calls for a main-container at 960px wide, with two containers inside of it, one large-container at 556px wide and one small-container at 331px wide. If we were content with pixel values, and that everyone had the same size screen, we might do this:

.main-container {
  width: 960px;
  margin: 0 auto; //centers the page
}
.large-container {
  padding: 0 18.25px; //fill out the container widths
  width: 556px;
}
.small-container {
  padding: 0 18.25px; //fill out the container widths
  width: 331px;
}

This will do the job on screens larger than 960px, but, definitely not on screens smaller than that. If we want to make our grid more responsive, we could throw in some calculations. Don’t be scared! Remember, target ÷ context = result. So, 556px ÷ 960px = 0.5791666666666667. Bump up that number by a factor of 100 and you get 57.91666666666667%. That’s the large-container width. The small-container width is 331px ÷ 960px = .344791666666667, or 34.4791666666667%. Our content is almost to 100% width (960px). We just need to figure out the padding of each element. To do that, we take the remaining width of 73px, divided by 2 to distribute between the two elements, and divided by two again to distribute to either side. That’s a padding of 18.25px, or 1.901041666666667%, or a total combined padding of 7.604166666666667%, which, when added to our previously calculated element total (92.39583333333337%) equals 100%. Let’s plug these numbers in:

.main-container {
  width: 960px;
}
.large-container {
  padding: 0 1.901041666666667%;
  width: 57.91666666666667%;
}
.small-container {
  padding: 0 1.901041666666667%;
  width: 34.4791666666667%;
}

Here’s the demo:

See the Pen Percentage over Pixels by Nate Northway (@the_Northway) on CodePen.

So, using percentages over pixels can help, for sure. But that’s just the first step. The next step is knowing when to break that design and go for something else. Using margin: 0 auto on larger screens helps your site stay centered when it’s reached it’s max-width, but that doesn’t help on small screens. What? I haven’t talked about max-width yet?

Max-width

The max-width CSS Property is so great, really, it’s one of the best properties out there. Say your designer gets you a .psd designed at 960px. That’s great, that’s fine, you can code that out. But what if people have screens bigger than 960px? Do you change the design to be super wide? max-width becomes your friend, here.

@media (min-width: 960px) {
  #page {
    max-width: 960px; //your page is never larger than 960px
    margin: 0 auto; //and it's always centered
  }
}

Boom. If you want to have the background image/color/other elements go side-to-side of the browser window, the parent element (like <body>) can always be set to a larger width. Personally, I set my HTML up to account for this, as follows:

<body>
  <header>
    <div class='container'>...</div>
  </header>
  <main>

  </main>
  <footer>
    <div class='container'>...</div>
  </footer>
</body>
body,
header,
footer {
  max-width: 100%;
}
.container,
main {
  max-width: 960px;
  margin: 0 auto;
}

This way, the navigation, site title, footer links, and all content is always center aligned and, more importantly, on the same grid that everything else exists on. The overflow of the background colors and borders moves to the edge of the screen, making your site look full, rather than clipped and pasted on to the page. max-width is great, isn’t it?

Ok, so onto collapsing now, yeah?

Using media queries, percentages, and a nugget of knowledge, we can collapse.

Utilizing the above examples, let’s work out some breakpoints. Breakpoints are a point at which the layout of the page changes to allow for better usability and readability. Usually, I make my breakpoints at about 2/3 and 1/2 of the original design. If the original design is 1000px, I’ll have a break point at 660px and another at 500px. The 660px breakpoint will collapse the columns to full-width, and the 500px breakpoint will hide the menu, bring up the navigation icon button, and further collapse any content. Here’s the code, going off of our last example.

@media screen and (max-width: 639.9999936px) {// 960px * 2/3
  .large-container,
  .small-container {
    width: 100%;
  }
}

This spreads out the containers to full-width. Now, at the smaller breakpoint, I’ll add in more media queries to further widen content, if needed. For example, articles with floated images. This is what an article with image might look like:

...
<article>
  <p>
    <img src='example.jpg' />
    XOXO glossier fingerstache quinoa. Cardigan migas affogato knausgaard keffiyeh, artisan lomo biodiesel meggings small batch gluten-free salvia tofu pop-up. Lomo cold-pressed aesthetic.
  </p>
</article>
...
...
p {
  width: 100%;
}
p>img {
  float: left;
  width: 33.33333333%;
}

So, the image is floated left and has a width of 33% of the parent element, the <p> tag. This probably looks fine on desktop, and possibly even on tablets, but on mobile, the image will be very small. So, in our media query, we can 1. ‘unfloat’ it, and 2. widen it.

@media (max-width: 480xp) {//960 * .5
  p>img {
    width: 100%;
  }
}

Here’s a demo of that (probably best to view it in CodePen):

See the Pen Responsive Resizing by Nate Northway (@the_Northway) on CodePen.

If that math is too crazy for you, there is another way to do it, which may be more intuitive, and uses more abstract definitions: Flexbox.

Flexbox Is My Hero

I love flexbox. I use it for everything. From <body> layout to create fixed headers and footers, to using it to display my <nav> correctly, to using it in articles and for tables, flexbox is awesome. Using it to help with responsive design takes a little bit of knowledge though. I’ll break it down best I can for you here, but I’ll also link to other articles written by people with much greater skill than I.

The Idea

The Flexbox Layout (as it’s officially known) aims at providing a more efficient way to lay out, align, and distribute space among items in a container, even when their size is unknown and/or dynamic. The primary idea behind it is to give the parent container the ability to change it’s children’s width, height, and/or order to best fill the available space. A flex container shrinks items to prevent overflow or grows/expands them to fill space.

The Basics

The parent, or flex-container, contains all of the flex-items, or children. It has 5 properties.

display

The display property defines the flex container and enables a flex context for it’s children.

.container {
  display: flex;
}
flex-direction

The flex-direction property defines an axis and the direction the flex-items are placed in the container. The values can be:
row: default value, left-to-right in ltr, right-to-left in rtl
column: top-to-bottom
row-reverse: right-to-left in ltr, left-to-right in rtl
column-reverse: bottom-to-top

.container {
  flex-direction: row;
  flex-direction: column;
  flex-direction: row-reverse;
  flex-direction: column-reverse;
}

flex-wrap

The flex-wrap property defines whether your rows will wrap or not. By default, rows will always try to fit on one line. Setting this property to wrap avoids overflow. It has three possible values:
nowrap: default value, single-line/left-to-right in ltr, right-to-left in rtl
wrap: multi-line/left-to-right in ltr, right-to-left in rtl
wrap-reverse: multi-line/right-to-left in ltr, left-to-right in rtl

.container {
  flex-wrap: nowrap;
  flex-wrap: wrap;
  flex-wrap: wrap-reverse;
}

flex-flow

Shorthand for flex-direction and flex-wrap. The first value is any of 4 from the flex-direction property, and the second value is any of the the 3 from the flex-wrap property.

.container {
  flex-flow: row nowrap;
  ...
  flex-flow: column-reverse wrap-reverse;
}

justify-content

The justify-content property defines alignment along the main-axis. It helps distribute extra free space left over when either all flex items on a line are inflexible or are flexible but have reached their maximum values. It also has some control over the alignment of items when they overflow the line. It has 5 possible values:
flex-start: default value, items are pushed towards the start of the container
flex-end: items are pushed towards the end of the container
center: items are centered along the line
space-around: items are evenly distributed along the line with equal space between them.
space-between: items are evenly distributed along the line, with the first item pushed to the start of the container and the last item pushed to the end of the container.

.container {
  justify-content: flex-start;
  justify-content: flex-end;
  justify-content: center;
  justify-content: space-around;
  justify-content: space-between;
}

align-items

The align-items property defines the default behavior for how flex-items are laid out along the cross-axis on the current line. It’s like justify-content for the cross-axis (perpendicular to the main axis). It has 5 possible values:
flex-start: cross-start margin edge of the items is placed on the cross-start line
flex-end: cross-end margin edge of the items is placed on the cross-end line
center: items are centered on the cross-axis
baseline: items are aligned according to their baselines
stretch: default, items are stretched to fill the container (still respects min/max-width)

.container {
  align-items: flex-start;
  align-items: flex-end;
  align-items: center;
  align-items: baseline;
  align-items: stretch;
}

align-content

The align-content property defines the behavior when there is extra space in the cross axis across multiple lines. It’s like align-items, but for wrapped lines of content. It has 6 possible values:
flex-start: lines pushed to the start of the container
flex-end: lines pushed to the end of the container
center: lines packed to the center of the container
space-between: lines evenly distributed, with the first pushed to the start of the container and the last pushed to the end of the container
space-around: lines evenly distributed, with equal space around each line
stretch: default, lines stretch to fill remaining space.

On to the flex-item’s properties.

order

The order property defines the order in which flex-children are laid out. By default, they are laid out in the source order, however, you may want to change this given different contexts. Any whole integer can be used as a value.

.item {
  order: 1;
}
.item {
  order: 2;
}

flex-grow

The flex-grow property defines how much an item can grow if needed. It’s value is unit-less and serves as a proportion which dictates what amount of the available space inside the flex-container the item should take up. If all flex-items have flex-grow set to 1, remaining space will be distributed evenly among all children. If one of the children has a value of 2, the remaining space would take up twice as much as the others (or try to, at least). The default value is 0.

.item {
  flex-grow: 1;
}

flex-shrink

The flex-shrink property defines the ability to shrink, if necessary. Whole integers are accepted but negative numbers are not. The default value is 1.

.item {
  flex-shrink: 1;
}

flex-basis

The flex-basis property defines the default size of an element before remaining space is distributed. It can be a length, like 20%, 20px, or 20rem, or a keyword. The auto keyword means ‘base this items flex-basis off it’s width or height property’. If set to 0, the extra space around content isn’t factored in. If set to auto, the extra space is distributed based on it’s flex-grow value.

.item {
  flex-basis: auto;
}

flex

The flex property is the shorthand for flex-grow, flex-shrink, and flex-basis. The flex shorthand should be used as it sets the values of all three properties intelligently.

.item {
  flex: 1 1 auto; //flex: <flex-grow> <flex-shrink> <flex-basis>
}

align-self

The align-self property overrides the the default item alignment or the one specified by align-items set in the parent element’s declarations. It defines the behavior for how this flex-item is laid out along the cross-axis on the current line.
flex-start: cross-start margin edge of the item is placed on the cross-start line
flex-end: cross-end margin edge of the item is placed on the cross-end line
center: item is centered on the cross-axis
baseline: item is aligned according to their baselines
stretch: item is stretched to fill the container (still respect min/max-width)

.item {
  align-items: flex-start;
  align-items: flex-end;
  align-items: center;
  align-items: baseline;
  align-items: stretch;
}

Putting it all together

So, now we’ve got some flexbox knowledge, some knowledge on percentages, and some knowledge on why we need to make things different sizes on different screens. Let’s put it all together. Let’s assume that I don’t know exactly how wide my main content area and sidebar should be, but I’ve got a good estimate that the .main-content wrapper should be 3/5 of the screen width, the .sidebar should be 1/5 of the screen width, and the remaining 1/5 of space should be evenly distributed. We can use flexbox to do this job!

...
<div class='wrapper'>
  <div class='main-content'>...</div>
  <div class='sidebar'>...</div>
</div>
...
.wrapper {
  display: flex;
  flex-flow: row nowrap;
  align-items: stretch;
  justify-content: space-around;
}

.main-content {
  width: 60%; // 3/5
  flex: 0 1 auto;
}

.sidebar {
  width: 20%; // 1/5
  flex: 0 1 auto;
}

This sets the width of the items to 60% and 20%, respectively. No need to set margin or padding, this is done by assigning the space-around value to justify-content in the parent element. Here’s a demo:

See the Pen Simple Flexbox Demo by Nate Northway (@the_Northway) on CodePen.

This is great, and would work fine, but only until you get to the point where your content starts overflowing it’s containers. This is where things get real fun. We can set a media query to the point where content starts to overflow. In this case, let’s say it’s at 500px screen width. Inside the media query, we set the width of the flex-items to 100%, the flex-flow property of the flex-container to column nowrap, and violia, we have a collapsing system.

See the Pen Simple Flexbox Demo With Collapse by Nate Northway (@the_Northway) on CodePen.

Figuring out where to collapse your system

It takes a bit of trial and error. First off, know that no design system is perfect. Figuring out your breakpoints can be tough. Bootstrap’s grid system is as follows:

Extra-small: < 768px
Small: >= 768px
Medium: >= 992px
Large: >= 1200px

I think that’s a good starting point for figuring out your own breakpoints, but it may not serve you quite as well as others. I get my numbers on a per-project basis. If the design is very complex, using a lot of small elements, my breakpoints are usually numerous and closer together. If the design is simple, two or three columns, I usually have two or three breakpoints, spread apart. It depends on context, is what I’m trying to say, just as anything in web design: context is king.

I use a lot of other sources when I write things.
The CSS-Tricks Guide to flexbox is a wonderful reference that I use quite often.
I highly suggest reading Ethan Marcotte’s book, Responsive Web Design. And if you’re a podcast listener, I strongly suggest subscribing to his Responsive Web Design Podcast, as well.

Mobile Menus


Mobile menus are seen throughout the internet. The way mobile menus collapse is
summarized by one image: the hamburger icon.

The Hamburger Icon
The Hamburger Icon, in all it’s glory

But going from a fully expanded menu on desktop to a menu that has to be
expanded based on user input isn’t as simple as one might think. Sometimes, some
CSS & JavaScript is necessary. I’m going to walk you through my method to
implement an effective menu collapse.

First, the markup

Some frameworks and developers encourage you to bloat your HTML by creating a
<nav> element with two menus inside, one with id='mobile-nav' and one with
no id or id='nav'. I’m certain that’s not necessary and only serves to
complicate things.

My method goes a little more like this: Simplify the markup so the menus are the
same across platforms. Include the hamburger icon, but hide it above your
breakpoint. Clicking the hamburger icon triggers the menuToggle(), which tests
the #menu for it’s class and assigns it the opposite class. In the CSS, define
the 'hidden' class to display: none; and the 'active' class to
display: inline-block;. Hiding and showing the hamburger icon can be done in
CSS, as well. Here’s the markup:

<nav>
    <button onClick='menuToggle()' id='hamburger'>
        <img src='hamburger.png' />
    <button>
    <div id='menu' class='hidden'>
        <a href='#'>Link 1</a>
        <a href='#'>Link 2</a>
        <a href='#'>Link 3</a>
    </div>
</nav>

This menu serves two purposes: easier understanding of the markup and definite
consistency between larger screen views and smaller screen views. Encouraging
use of different menus opens the door for menu items to be missed or a similar
oversight. A menu that shares the same markup between small and large screen
views encourages consistency and eases inserting new items or removing old items
or refactoring or just updating your site.

The CSS Looks something like this:

#hamburger {
  display: none;
}
@media (max-width: /*your breakpoint here*/) {
  #hamburger {
    display: inline-block;
  }
  .active {
    display: block;
  }
  .hidden {
    display: none;
  }
}

And that’s all there is to the CSS, besides styling it the way you want. Now to
the easy part: the JavaScript

$menu = document.getElementById('menu');
function menuToggle() {
  $state = $menu.className;
  if ($state === 'active') {
    $menu.setAttribute('class','hidden');
  else {
    $menu.setAttribute('class','active');
  }
}

Again, pretty simple. All of this works together in harmony. A demo of
the above with a little extra CSS for styling is found on my CodePen. As you can
see, JS can be used to effectively control a nav menu. It can be done quickly
and easily, too. If you want your menu to look fantastic all it takes is a
little more CSS. You can go even further and add another button in the #menu
which calls menuToggle() if you want your menu to overlay the whole page. I’ve
used this method lots and lots and find it effective, explainable, and easy to
work with.

Project Flow

Prior to starting a relationship with a client, I like to walk them through the website design and development process. Often times, a lot of standard business practices are implemented, however, there are a few things unique to web design that (in my experience) have come as a surprise to the client.

The first step: Quote Request/Initial interaction

Normally, the first thing a potential client asks for is a quote. They give me a five minute breakdown of what their site needs, a timeframe, and a possible budget. They communicate this after hearing that I build websites, in a hasty email, or through the contact form on my website. They usually end their sentence with "How much will that cost???". I don’t know. I could do what you describe, but to accurately answer your question, we need to move on to step two.

Step two: Project Discovery

Project discovery helps me answer a potential client’s first question: how much will their website or app cost to build? My quote depends upon a lot of things, generally:

  • What technologies need to be implemented

  • How long it will take

  • How busy I am

  • What type of client you are

  • Features

  • Complexity of Design

I’ll break these variables down.

What Technologies Need To Be Implemented

I work mainly in HTML, CSS, JavaScript, PHP, and MySQL. I work with CSS preprocessors, jQuery, PHP libraries, and SQL extensions for PHP. Each of these skills has their own cost associated with them. A half hour of HTML & CSS work costs less than a half hour of PHP Programming, which also costs less than a half hour of MySQL programming.

I determine the technologies necessary to build your site from learning what problems your site needs to solve. Is there a lack of information in the world? Do you need a static, informational site? HTML, CSS, and JavaScript oughta do the trick. Do you need a blog attached to it? Add in PHP and MySQL. Do you also need your site to be translated? There’s an extra week (or two or three depending on which languages you need). Will your site have users with privileged access (such as admins to edit, delete, and add posts)? Tracking and analytics? All of these things add up.

Basically, the more complex, the more expensive.

The Site Itself

Site features and design complexity take skill to build, test, rebuild, debug, deploy, maintain and hotfix. The more complex your site or design, the higher your price point will be.

How Long Will It Take To Build Your Site

A big factor of your quote is time. If your site is going to take a lot of my time, it will be more expensive. There is a lot that I do in my life and web design isn’t the only thing. If your project deadline is in a short time frame and you need work turned around quickly, this probably means that I’ll be cutting into my personal time to build your site, which probably means that, unless I really really like you, you’ll be charged a premium for this time.

Generally, I work out time based on a few things. First, I take a look at the pages, functions, design, and every other aspect of the site and use my previous experience to gauge how many hours it will take me to build it. Factoring in an additional 5-10 hours of non-response time (link to ‘non-response time’ article), I then compare my hours estimate to your project deadline, based on 8 hours of work in a day, 24 per project per week. If, at these daily and weekly rates, your project deadline can not be met, I add $15 per hour to my hourly charge and adjust my timing so that your project can be delivered on time.

How Busy I Am

At any given point, I’m juggling at least 3 clients. Since I like to spend at least 24 hours in a week on each client, that means I’m juggling 72 hours of work per week before factoring in non-response time and 42 hours after factoring that in. So, if I have three clients and you want to jump on my client list, I’ll be honest with you and tell you if you can fit on my schedule. Generally, I try to flip every project within 3 weeks. Anything that takes longer than that should be considered a long-term project and we’ll be talking about gainful employment at that point. If you can fit in my schedule, I’ll give you a lower quote. If I’m really busy, your quote will be a little higher, simply because I’m usually tired at the end of the day as it is.

What Type Of Client Are You?

In a nutshell there are three types of client: the easy client, the mediocre client, and the annoying client. If you’re an easy client, your quote is lower. If you’re the mediocre client, your quote is unchanged by your client-type status. If you’re the annoying/helicopter client, I’m charging you as much as 20% more than the mediocre client.

Finishing up with Project Discovery:

Usually, at the end of project discovery, I’ll ask a few questions pertaining to design and UI/UX. I’ll ask what sites, colors, designs, artists, and cars you like. This helps me get a feel of what I’ll be aiming for design wise. Usually, I’ll try to sketch out some design elements, bring up some ‘inspiration’ sites, and explore some design patterns and UI/UX patterns using the demos that I have already built (mostly with CodePen). This really helps me determine project complexity and how it is to work with you as a client.

Once we’ve finished project discovery, I’ll be very clear about whether or not I think we could have a good relationship and start talking about the quote and the contract that I’ll be sending over for review.

Step Three: Quote Delivery

After we’ve determined all of the things that factor into the price of your site, I itemize the total quote and break it down. Usually, it looks a little something like this:

   Static Site: $   750
          Blog: $   350
 Dashboard/CMS: $   500
        Design: $   500
Implementation: $   250
           SEO: $   250
         Total: $ 2,600

This quote is further broken down in person so I can explain why and how I came up with these numbers. I’ll email this quote to you and request a meeting to answer any questions and discuss our contract.

Step Four: Quote and Contract

So you’ve got the quote. You know what you should budget. You talk to your boss. Your boss says ‘bring his price down’. You want to haggle a little bit. That’s cool. Haggle away. Everytime you suggest the price of your site to go down, it goes up because you’re becoming more of the annoying client.

Anyways, once we’ve agreed on a quote, we can start talking about the contract. Generally, I bring up a template I have and we talk it through, discussing the stipulations and applying any changes unique to our relationship. Doing it this way helps avoid confusing and lets the client know that I really am there for them.

After we negotiate the contract, I tell you that I’ll be emailing you within a week. Then I drop the contract off with my lawyer and make sure that nothing illegal or sketchy has been agreed upon, and I call you back for a contract signing.

Step Five: Contract Signing

Woah. Finally to the actual start of our relationship! At the contract signing, we sign the contract and you pay me 20% of the total quote. Then i run away in a frenzy and start building your website.

Step Six: iterative Design

Once I’ve built out most of the features, I put a development site on my server and give you access to it. You look at it, tell me what you like, don’t like, etc, and I explain or fix these issues. Usually, this is also a great time to test UI/UX to make sure it meets the needs of your customers. We do this a few times.

Step Seven: Testing

I test my sites a lot. I have a small team of beta testers whom I pay to break the sites I have built. I also try to break sites. This helps me identify edge cases and provides real world feedback so your site doesn’t break ‘out in the wild’. Once I’m satisfied that no more edge cases are being discovered and there are no errors with your site on any platform that we’ve deemed necessary, we can move on.

Step Four: Pushing the Site

Now that we’ve iterated over design and features and tested, we can push. This really isn’t hard and doesn’t take long, but it’s a milestone.

Step Five: immediate Maintenance

For one week after pushing your site, I provide 24/7 maintenance. I don’t mean that I don’t sleep for a week, I mean that if I’m awoken by a call from you saying that your site is down, I wake up and fix it. Sometimes this has to with DNS errors, floods of bots, crawlers, and people trying to break into your site. There are also some things that could happen with your web server configuration that need adjusting. That’s what this first week of being live is about. Finding those things and fixing them before they become too much of a problem.

Step Six: We’re Done!

Once that week of maintenance is over, you pay your final invoice, and our relationship is almost back to where it started – but now, you have a website.

Frameworks: Bleh.

I want to get away from frameworks. I find that frameworks often require a lot of overrides or not enough functionality, especially in a non-static site. Additionally, I find that so-called responsive frameworks, while boasting plenty of features, often lack consistency across devices. For example, on my site, a thick white right border appears on the index page. For the life of me, I can’t debug this, and it’s annoying the crap out of me. So I’ll be rebuilding my personal site and staying away from frameworks to focus on building truly responsive pages. Since Streampost (the platform this blog is built on) is based on MaterializeCSS, I don’t know what the future for that holds. I think for now it’s best to stay with a framework if I want to keep it going because I’m leading a rather busy life as of late; however, I also realize the importance of ensuring a responsive site, and if Materialize isn’t able to achieve that to my specifications, I’d like to step away from it.

Tel: What?

Alright, so we all know (or should know) about prefixing href attributes with
the ‘mailto:yadda@yadda.com’ to get the link to open the mail client on the
user’s computer and send an email. This is groovy. Did you know the href
attribute accepts other prefixes, too? Like, if you’re targeting mobile users
and want an easy way for them to call you:

<a href='tel:414-123-4567' rel='telephone'>414-123-4567</a>

^ That would do the trick. You can also prefix with ftp: and telnet: (to support
FTP and telnet protocols) and some other interesting (yet not-so-applicable today)
prefixes. Read about it on IETF’s site.

Streampost

I have been asked by a few people for recommendations of blogging platforms that
aren’t hard to use and aren’t difficult to understand. There are many, many,
many blogging platform options, but none of which (that I have found) that just
do those two things and nothing else. Of course, there are utilities that come
with these tasks: user management, simple customization (like the blog’s name
and description), and updating (the blog itself and posts/static information).

So, I went and built Streampost

Streampost works on a MySQL database and uses PHP to assemble, insert, and read
from the database tables. Setup is really easy and well-documented, managing the
blog is dead simple, and the zipped file is only 90k in size. I’ve learned a lot
of stuff while building this (but I’ll save you from that list) and I’m really
happy to migrate things over there. Over the next few days and weeks, I’ll be
implementing Streampost here and, sadly, be getting rid of Void ;(

You can check out Streampost here

Planned Updates

Currently, Streampost is in a limited private beta and isn’t suggested for
production. I’m planning on releasing a few major updates for version 1.0.
Namely: Improved Security, Improved User Management, and Improved Blog
Management

Improved Security
Security is extremely important, especially today. V1.0 will include security
updates which better manage server – client relationships, password and session
management. Improving security is a top priority.

Improved User Management
The ability to update email addresses and passwords, and manage multiple users
is a necessity. V1.0 will include the following updates to user management:

  1. Password and email address updates
  2. Multiple users
  3. User Privileges (to have one admin and ‘n’ amount of ‘posters’)

Improved Blog Management
Most modern blogs include a utility to update previous posts, manage things
like the blog title, about section, footer text, and other static information.
Streampost will also feature this utility, with the options to edit post titles
and content, the blog title, about information that appears in the side bar,
footer information, and contact information. Additionally, in a far future update,
the ability to change the host, database information, and other site-critical
information will be introduced.

Thanks for reading. I hope you check out Streampost and contact me for the limited beta if you’d like (and you know what a development site is)