Sass is a superset of CSS that “compiles” down to regular CSS usable by any browser. It adds features such as functions, logic, and loads more.

Sass already had the concept of lists that allow a one-dimensional list of values to be defined; Sass 3.3 introduced maps – a series of key-value pairs.

Defining a Sass Map

To define a variable called team-colors containing a map of values (in this case a map of soccer teams and their colors):

$team-colors: (
    australia: #F7AD31,
    england: #FFF,
    sweden: #FFE700,
    japan: #435AAD
);

Iterating over a Sass Map

Now we can iterate through all the team names and access their color values:

@each $team, $color in $team-colors{
    .#{$team} {   
        background-color: $color;
  }
}

This will create a CSS class with the name of the team (using Sass interpolation syntax) and its associated background color:

.australia {
  background-color: #F7AD31;
}

.england {
  background-color: #FFF;
}

.sweden {
  background-color: #FFE700;
}

.japan {
  background-color: #435AAD;
}

There’s also a number of functions for manipulating maps such as map-get and map-has-key.

To learn how to simplify your CSS and save time writing it with Sass, check out my Pluralsight course.

You can start watching with a Pluralsight free trial.

SHARE:

I’ve been tinkering with an idea for a new open source project called NamedColors.

As its name suggests, it’s a list of color values (hex RGB) with associated names. In addition, a number of related “emotions” can be associated with each color.

A Named Color is defined as:

<NamedColor>
    <Name>MetroUITeal</Name>
    <RGB>00aba9</RGB>
    <Emotions>
    </Emotions>
</NamedColor>

You can see the current (short) list on GitHub.

The idea is to create a number of projections for use in different programming languages / platforms. For example CSS, Sass, and .NET PCL.

The project is in its early stages at the moment, and I’m not sure what applications people will find for it – it will be interesting to see what happens.

Projections are created using T4 templates.

There are other projections planned, such as a XAML dictionary of colors and brushes.

If anyone has any other ideas for projections feel free to add an issue or send me a pull request – also for adding other named colors.

Eventually for .NET there will be a NuGet PCL available containing all the named colors and way to say “give me a sad color”, etc.

SHARE:

My new Pluralsight course was recently released that shows how to use Sass when developing ASP.Net web applications.

Sass (CSS with superpowers) allows the creation of regular CSS, but produce it with loads of cool features that regular programmers know such as variables and functions.

Sass is a superset of CSS and has a .scss file extension. A CSS file is a valid Sass (.scss) file.

A tool “compiles” the Sass .scss file to regular CSS. One way to do this in Visual Studio is to install the free Web Workbench extension. Once installed, whenever you save the .scss file, Web Workbench will create the accompanying .css file as shown in the following screenshot:

(Notice here the minified version is being created by Web Workbench because the full version is installed.)

Sass Variables

Sass variables can be defined and then used wherever regular CSS property values are used. For example, the following shows 3 variables declared and used in the .scss file:

$main-brand-color: pink;
$secondary-brand-color: #111;
$base-font-size: 50px;

body {
    background-color: $main-brand-color;
    color: $secondary-brand-color;
    font-size: $base-font-size;
}

This produced the following .css:

body {
  background-color: pink;
  color: #111111;
  font-size: 50px; }

Mixins

Mixins decrease the amount of boilerplate CSS we need to write. For example using vendor prefixes throughout the stylesheet. Rather than writing all the prefixes by hand we can declare and invoke a mixin:

@mixin border-radius($radius){
    -webkit-border-radius: $radius;
    -moz-border-radius: $radius;
    border-radius: $radius;
}

.border {
    @include border-radius(10px);
}

This produces the following CSS:

.border {
  -webkit-border-radius: 10px;
  -moz-border-radius: 10px;
  border-radius: 10px; }

Inheritance

Repetition can be reduced with Sass inheritance. In the following example, happy and sad inherit from greeting:

.greeting {
  border: 1px solid #000;
  padding: 10px;
}

.happy {
  @extend .greeting;
  border-color: yellow;
}

.sad {
  @extend .greeting;
  border-color: grey;
}

This produces:

.greeting, .happy, .sad {
  border: 1px solid #000;
  padding: 10px; }

.happy {
  border-color: yellow; }

.sad {
  border-color: grey; }

Now in the HTML, when the happy or sad class is used, the element will also get the greeting styles without having to apply both classes explicitly.

These examples just scratch the surface of the feature set of Sass. To learn more check out the official site or my Simplifying CSS in Visual Studio With Sass Pluralsight course.

You can start watching with a Pluralsight free trial.

SHARE:

I found out about these units this week so I wanted to have a play with them.

The CSS units: vw, vh, vmin, and vmax allow sizes to be specified relative the the browser window size (or the “initial containing block”).

So 1 vw is equal to 1% of the viewport width and 1 vh is equal to 1% of the viewport height.

vmin and vmax return the smaller and larger respectively of vw or vh.

There is good support  for vw and vh in modern browsers with some partial support for vmax, overall about 55% of browsers offer full support, 20% partial support.

So for example to center a div vertically in the browser we could set its height to “50vh”  (50% of the viewport height) and set its top margin to be “25vh” (or a quarter of the viewport height), thus leaving a quarter below the div.

So here’s a screenshot of this in action in a tiny browser window (the white is the div):

And after resizing the browser:

More...

SHARE:

Sass (Syntactically Awesome Style Sheets) tries to make CSS fun again.

It's a set of "extensions" on top of standard CSS that make it easier to write and maintain style sheets.

A Sass file compiles down to regular CSS so it doesn't require any special browser plug-ins.

This article is aimed at Microsoft developers but the Sass language sections apply to anyone wanting to get an overview of Sass, regardless of the web programming platform or IDE you're using.

More...

SHARE:

The redesigned Don't Code Tired is now live. This article wraps up the series with a look back at what I learned and what things are still outstanding.

Key Things I Learned

I am not a designer. Ok so I knew this anyway, even though I learned heaps from this process if I were to undertake it again I would at least get some feedback along the way from a designer.

I love SASS

CSS Media Queries are awesome. It is so easy to apply different styling based on browser width, the hard bit is deciding what you want to show

I Love SASS. SASS really does make writing CSS a more pleasurable experience. Even though I feel I have only just scratched the surface of what is possible I am hooked and will be using SASS on any project I can in the future.

Other Learnings

• Design concepts such as: mobile-first, typography-out, designing with personality, content inventories, etc.
• Basic colour theory
• Controlling mobile browser rendering and zooming with meta tags
• Custom fonts using @font-face
• New semantic HTML5 elements
• ARIA Landmark Roles

Evaluating the Final Design

I though it is good to look at the final outcome and compare it against what I initially set out to do.

Voice

"DontCodeTired's voice is friendly and personal, it's speech-like and somewhat casual using contractions and occasional slang over formal and stuffy speech. It doesn't try to be overly cool but is not afraid to have some fun on occasion (as long as it doesn't detract too much from the information)."

I think the the voice of the messages, prompts, navigation, etc. upholds this design goal. Some existing articles in the blog may not, but I should refer to this when writing future articles.

Colour

"DontCodeTired's colours are clean and mostly understated. Where colour highlights are needed they are saturated and bright. Solid blocks of colour are preferred to gradients."

There are no gradients in the final design, but the final colours I chose are not "understated", quite the opposite the purple is quite bright. I'm not sure how I feel at this stage, I may revisit the colour palette at a later date, but due to the awesomeness of SASS I can just change a few variables and the whole colour scheme will be updated.

Typography

"DontCodeTired is all about the article content. Main content typography will use clean readable sans-serif fonts with a predictable type ramp. DontCodeTired's overall design will be based heavily on the readability of text."

The chosen fonts meet the above brief, if I have one criticism it's that the type ramp for headings could be a little better. The first few heading levels are good, but at the lower levels there is not much difference in size.

General Style

"Taking some ques from Metro design, interface elements will mostly focus on content over chrome, elevating the article content to the fore, relegating non important navigation and other elements to the ground."

This design goal has been well respected throughout the design. There are not a lot of boxes to "constrain" content, instead proximity and relative size are used to group content.

Other Observations

• There is too much empty space in desktop version in the header
• The header colour may be too bright
• Tweet button on the home page is showing the same value for each post
• Max width should look prettier once the browser expands beyond this point, perhaps centred or other design element to fill the space
• The SASS needs refactoring
• Content still transmitted to mobile devices even when not shown
• Loading speed on mobile devices needs to be quicker, especially the first page. This may need some CSS and JavaScript bundling and minification. The number of posts on the first page may also need to be reduced
• Tag cloud and "things I've built" section need to be able to be accessed somehow on mobile devices where the sidebar is hidden

SHARE:

Creating the Second Responsive Breakpoint

The next responsive breakpoint kicks in at 970px width. At this point the first of the sidebars become visible. This "about me" sidebar contains a basic bio and the last tweet I made, in addition to some advertisement space.

The tone of this sidebar is muted (other than the ads) with grey text and a black and white bio photo so as not to detract too much from the main article content.

I think the measure (length of horizontal line of text) becomes a little long before this break point kicks in, but is an acceptable compromise.

Creating the Third Responsive Breakpoint

The third breakpoint kicks in at 1200px. It introduces the second of the sidebars on the left side.

This sidebar contains common blog-type widgets such as tag clouds and links. Again the text is muted so as to not detract too much from the main content.

Defining a Maximum Width

As the width continues out from the third breakpoint the measure becomes increasingly long. Left unchecked the readability quickly becomes poor as the eye has a long way to travel from the end of one line on the right to the start of the next line on the left.

At some point a maximum point is reached where the text should no longer expand. This point occurs at 1470px, which still allow a pretty long measure but again is somewhat of a compromise. This is defined in the CSS using:

html {
max-width: 1470px;
}

At some point I might make the whole body centre aligned but for now I'm ok with this.

Using SASS to Style Tag Cloud Text Sizes

The blogging engine I'm using renders the tag cloud by adding classes to the items depending on the prominence of those tags in posts. Whilst I could have simply hard-coded the font sizes in these, it looked like a good opportunity to use SASS.

First I defined a couple of SASS variables, one to set the base font size for the least frequent tags, another to set what the increment is between each size. Then it's just a matter of multiplying the base size by a multiple of the increment. This enabled me to play with different combinations really quickly to get the look I wanted.

The final chuck of SASS looked like this:

$tcBaseSize: 0.5;
$tcIncrement: 0.3;
.tagcloud a.biggest {
@include font-size($tcBaseSize + (4 * $tcIncrement));
}
.tagcloud a.big {
@include font-size($tcBaseSize + (3 * $tcIncrement));
}
.tagcloud a.medium {
@include font-size($tcBaseSize + (2 * $tcIncrement));
}
.tagcloud a.small {
@include font-size($tcBaseSize + (1 * $tcIncrement));
}
.tagcloud a.smallest {
@include font-size($tcBaseSize);
}

Styling the Bullet Points in Unordered Lists

I wanted to change the bullet points from the default black circle to a coloured square as a nice visual embellishment.

The problem is that other than using images for bullets, this can be hard to do in CSS. Also I needed the solution to work with all the old posts that used unordered lists.

The solution I came up with (whilst a bit of a hack) seems to work nicely with the above constraints.

The solution involves using some jQuery to find all the <li> elements, and inject a <span> to wrap the inner content. This span has an inline style applied to set the colour to the that used by the rest of the article copy.

function wrapListItemContent() {
var standardTextColor = $("#hiddenTextColorJQueryHook").css("color");
$("ul li").each(function () {
var t = $(this);
t.html('<span style="color: ' + standardTextColor + '">' + t.html() + "</span>");
});
}

The hiddenTextColorJQueryHook is an element that I inject whatever SASS colour variable I'm using, so that if I change the SASS colours there will be no change required in the JavaScript.

The downside of this approach is the bullet points and text will appear coloured until the jQuery document ready fires. I may decide to pull this once I get into final device testing.

Screenshots of the New Breakpoints

SHARE:

At this point in the redesign process the mobile layout and design is (mostly) complete. The next stage of the process is to look at "non-mobile" designs.

Again I am going to take a typography-first approach. What this means is looking at the font size, measure, etc. at different browser widths and trying to maintain a nice reading experience as the width increases.

Responsive Breakpoints

A response design breakpoint is that point where one set of CSS styles takes over from another. Each breakpoint represents potentially different layout, styling, content and functionality. Responsive breakpoints are implemented using CSS3 media queries that enable a different set of CSS to be applied depending on the size of the window.

A response design breakpoint is that point where one set of CSS styles takes over from another.

As I am thinking typography-first, I will let the breakpoints occur naturally where they arise rather than designing up front. I'll be doing in-browser design rather that mockups in a drawing or prototyping application.

A good guide (see below for recommended tools) for the different resolutions is the Chrome Window Resizer plugin.

Will it Look Good on an iPad?

It's not a good idea to think of individual devices because we don't want to have device-specific renderings; this is not sustainable or maintainable: every time a new device is released we would have to create a breakpoint for it.

If the user has a browser that supports media queries then we can write CSS specifically for certain situations

We can however look at the resolution of an iPad (for example) and add this to the Window Resizer plugin to give us another useful reference point. I have added a 1024 x 768 (iPad landscape) and 768 x 1024 (iPad portrait).

Arranging the CSS (SASS)

Currently I have a 0-up.scss SASS file that generates a 0-up.css file. This is being included and is not surrounded by a conditional media query. This means that these styles will always be used, unless they are overridden by styles that occur later in the CSS.

The styles that are specified later on will be surrounded by media queries that represent the responsive breakpoints in the design.

The First Responsive Breakpoint at 768px

At 768 pixels wide the measure (of the text) is still nice as is the font size. The thing that I want to introduce at this breakpoint is a change in the header.

I want to replace the drop-down select box with simple hyperlinks. I also want to add the search box into the header.

Creating a Breakpoint Using CSS Media Queries

The first thing we need to do is create a new (SASS) stylesheet to represent the styles that will be overridden, i.e. 768-up.scss.

The first thing in this stylesheet is to create the media query:

@media all and (min-width: 768px){
}

Weirdly, the Chrome Window Resizer seems to incorrectly report the width so at 768px the media query didn't kick in (I testing this by adding html { background-color: black;} and using the plugin to change to 768px, but the background was still white.

Some other tools I tried:

• http://resizemybrowser.com/
• http://www.responsinator.com/ *Recommended
• http://responsivepx.com/
• http://nightly.mozilla.org/ *Recommended Install and go to Tools, Web Developer, Responsive Design View

Hiding the Drop Down Select Menu

In the 768-up file:

@media all and (min-width: 768px){  
#menuNavSelect{
visibility: hidden;
display: none;
}
}

Showing the Hyperlink Navigation

In the 768-up file:

@media all and (min-width: 768px){  
#menuNavSelect{
visibility: hidden;
display: none;
}
#menuNavList {
visibility: visible;
display: block;
}
}

Showing the Search Box

It's at this point that the idea of having multiple SASS files to represent the breakpoints becomes problematic. The problem is that if we want to use any of the mixins or variables that are defined in the 0-up.scss file we would have to copy and paste them creating a maintenance overhead.

There is an import rule is SASS that can import another .scss file but it looks like it imports as plain CSS if there are any media queries.

So rather that have separate SASS files for each breakpoint, I've decided to have one SASS file, inside which all the media queries will be defined.

To show the search box, in the 768-up section of the scss file we add some styling for headerSearchContainer:

@media all and (min-width: 768px){  
#menuNavSelect{
visibility: hidden;
display: none;
}
#menuNavList {
visibility: visible;
display: block;
}
#headerSearchContainer {
visibility: visible;
display: block;
}
}

These are the only changes I want to make at this breakpoint. I may makes some tweaks later, but for now this is fine.

Screenshots from the awesome Responsinator: 

SHARE:

Now I have all the elements in place (semantic HTML5, typography, copy) in place I can start to think about the visual styling and decoration.

The first thing is to refer back to the initial Design Persona Visual Lexicon:

"DontCodeTired's colors are clean and mostly understated. Where color highlights are needed they are saturated and bright. Solid blocks of color are preferred to gradients."

Bearing this in mind I came up with a list of style attributes that I want the visual design to posses:

• light
• spacious
• digital
• clean
• crisp
• bright
• saturated color
• open
• simple

Choosing a Color Scheme

This step is about creating a set of colors that will work together in the design.

Color is a powerful tool that will set the overall tone of the site. There is a whole psychology of color which I would love to learn more about, but this color wheel gives a good idea, what's really interesting is the cultural-specific attitudes to colors.

Looking back at the brand traits from part 2:

• knowledgeable but not condescending
• clear but not elitist
• valuable but not limited
• friendly but not chatty
• honest but not mean

As we want a sense of friendliness, the first color to rule out are the reds. Reds signal danger (for example blood is red) so it's a very strong color and according to the color wheel is also associated with aggression.

The knowledgeable and honest traits suggest pinks (truth), purples (wisdom), blues (wisdom) and browns (credibility). Comparing these candidate colors to the style attributes above (particularly bright and saturated) rule out the browns.

The honest brand trait leads us to pinks (truth), yellows (honor) and again browns (credibility).

So, in addition to black (which I have already decided for the main article content) and white (for the background), I have the following candidate colors:

• pinks
• purples
• blues
• yellows

Using a tool like Kuler I can now start to put together some color swatches.

Below is an initial attempt at some color schemes:

Interestingly, when playing with the different color rules some of the colors I had thought not to use appeared, such as browns and greens. I think it's important to remain open-minded throughout the design process so it's ok to explore variations.

In the case of the greens I think this still fits into the overall feel I'm trying to create and the greens bring a sense of nature to the design. This natural feeling is somewhat at odds with the digital style attribute I outlined above, however I think the 2 can co-exist and the greens may offer a nice counterpoint.

I especially like the first and third schemes in the above image, however I don't think the first one offers enough contrast. I tried adding a green and slightly changing the hue/saturation of the others to get this:

Whilst there is a bit more contrast in this it still doesn't feel right. I know that is a very non-technical description, and I'm sure I have violated numerous color rules, but it doesn't feel very integrated and feels to me somewhat confronting or distant or disingenuous.

So I went back to scheme three and tried adding a purple into it:

Again this didn't seem right to me and scheme three kept calling out to me for some reason, so although I tried different permutations I'm going with my gut feel:

Using SASS to Define Colors

The awesome SASS let's us define variables, which includes variables to represent colors.

Defining Basic Background and Foreground

The first colors that need defining are the default background and foreground text. The background will be pure white, with the foreground text being an almost-black (to soften and slightly reduce the contrast) and make text a bit easier on the eye)..

$primaryContentBgColor: #FFF;
$primaryContentTextColor: #333;
html {
background-color: $primaryContentBgColor;
color: $primaryContentTextColor;
}

All Monitors Are Not Equal

Up until this point I've been using an Acer monitor plugged into my Lenovo X220T as my main screen for Kuler and playing with colors. An interesting thing happened why I viewed the colors on a physical Windows phone and on the laptop monitor. The colors were really different, with what I though were purples coming out as pinks.

This again highlights the importance of testing on actual devices early on.

Ideally I would calibrate all my screens with a hardware colourometer such as the Spyder. Obviously this would be basic requirement if I were a professional designer...

This is what the final color palette looks like when adjusted from my laptop screen and checked on a physical phone:

Defining The Other Colors

Up until this point I've mostly been doing in-browser design, i.e.using HTML and CSS to create wireframes\mockups. This enables early feedback of any potential browser problems and means that rendering of text is more realistic than if a graphics program is used.

At this point it makes some sense to open up an image editor (for example the free Paint.NET and throw around some colors. I added in the Kuler colors into Paint.NET palette as custom colors and then played around with different combinations just to get an initial feel for how I wanted to use the 5 colors, plus black and white.

Out of these three color concepts I've chosen to go with the right most one initially. The great think about using SASS color variables is that it's going to be super easy to change colors if I change my mind later.

Designing a Logo

So now I have a color concept I can think about a logo. I am not a graphic artist, so I am going to stick with a basic text-based logo which will work out better for everyone concerned.

To allow me to 'generate' logos at different sizes with no loss of quality I need to use a vector based format, rather than bitmap format. The free Inkscape allows creation and saving of vector based images in SVG format. The added advantage is that I might choose to use a native SVG file in the browser rather than rendering down to a raster image like a PNG.

Some initial design ideas:

Out of these I picked the one I liked the most and started to play with some theme colors:

The Finished Mobile-First Design

I consider the mobile design to be (mostly) complete, here's how it looks in Windows Phone emulator:

SHARE:

Redesigning DontCodeTired.Com Part 5 - Showing and Hiding Mobile Specific Elements

The idea of typography-out is that for websites where the textual content is king, it makes sense to elevate it to the thing of primary importance. The thing that drives the rest of the design. The opposite approach is to focus on the canvas as the first thing and work "inwards' to get to the content (text) last (putting "style" or "decoration" or "chrome" before content).

Letting Typography Lead the Design

What I mean by this is the way the article text fills the screen on the mobile emulator: how many characters\words per line (i.e. the measure), leading, font size, typeface choice. All of these basic typogographic principles (of which I am not an expert) will be applied to make the content readable. Above all, readability is the primary consideration.

(Starting to learn more about typography (and other aspects of design) has given me insight and great respect for professional web designers...)

I'll consider reading distance (how far people are likely to be from the screen) as this informs the choice of font size, etc. For tablet\desktop usage, the font size may need to be different to accommodate different physical reading distances.

Choosing a Typeface

The CSS3 @font-face rule allows us to use typefaces that are different from the standard web-safe fonts. It allows us to reference new fonts to use on our sites by loading a font file into the browser and then referencing it in the CSS.

There are (as with anything Web related) different formats (WOFF, EOT, TTF/OTF, SVG) that different browsers support. The awesome Font Squirrel makes it easy to generate the CSS - and they have a load of "commercial-use free fonts".

I chose PTSansRegular for body and PTSerifCaptionRegular for headings, generating the @font-face and downloading multiple font format files courtesy of the awesome FontSquirrel. For the less important elements such as the published time I chose PTSansNarrowRegular.

Setting up the fonts

FontSquirrel generates a stylesheet.css which contains the @font-face definitions. This file sets the font-weight and font-style to normal for each of the included fonts.

This can cause a problem where text will be doubly emboldened or italicized. For example, if the <em> style below is used, the browser may try to initializes an already italic typeface and you may get horribly double slanted (italicized) text:

em {
font-family: 'PTSansItalic', Georgia, serif;
}

To fix this we can edit FontSquirrel's CSS and specify font-style: italic; in the font-face:

@font-face {
font-family: 'PTSansItalic';
src: url('PTS56F-webfont.eot');
src: url('PTS56F-webfont.eot?#iefix') format('embedded-opentype'),
url('PTS56F-webfont.woff') format('woff'),
url('PTS56F-webfont.ttf') format('truetype'),
url('PTS56F-webfont.svg#PTSansItalic') format('svg');
font-weight: normal;
font-style: italic;
}

(You can do this for bold typefaces too..)

A Nice Vertical Flow

We want the vertical flow of text to look good. One way we can do this is to space things vertically in a consistent way.

The rem unit of measurement is a newer CSS concept with some support. It is similar to em in that it is a relative measurement, but unlike em it is relative to the root HTML element rather than the element's immediate parent.

As rem is not supported in older browsers we can specify a px value first and then a rem value. This could be pretty tedious, but again SASS makes it less painful.

The following extract of SASS defines some variables and a mixin to set basic typography properties:

/*
Variables
*/
$baseFontSize: 16; // size for px values and rem calculations, i.e. 1 rem = this value
$lineHeightMultiple: 1.5; // e.g. 1.5 = 150% line height
$baseVerticalRhythm: $baseFontSize * $lineHeightMultiple;
@mixin standardTypeMeasure($multipleOfBaseRhythm){
$px :$baseVerticalRhythm * $multipleOfBaseRhythm;
font-size:  $px + px;
font-size: $px / $baseFontSize + rem;
line-height: ($px * $lineHeightMultiple) + px;
line-height: (($px / $baseFontSize) * $lineHeightMultiple) + rem;
}

This mixin can then be called from our CSS rules:

time {
@include standardTypeMeasure(0.5);
font-family: 'PTSansNarrowRegular', Georgia, serif; 
}

This results in the following generated CSS:

time {
font-size: 12px;
font-size: 0.75rem;
line-height: 18px;
line-height: 1.125rem;
font-family: 'PTSansNarrowRegular', Georgia, serif; }

Browsers that do not understand rem will instead use the `px' value.

Investigating CSS Hyphenation

I experimented with CSS text justification and hyphenation but it didn't look great and current browser support at the time of writing is only 24.77%. I was testing in Firefox using the vendor prefix :

text-align: justify;
-moz-hyphens: auto;

A Nice Chrome Plugin

There is a nice Chrome browser plug-in which quickly lets you change the browser window to one of a number of preset sizes (e.g. iPhone, iPad etc.) or create your own.

For the mobile version I've been mostly using the Windows Phone 7 emulator, however this Chrome plugin will be great for future parts of the redesign.

In Conclusion

Throughout this section I've also been continuing to hide elements that are not good for mobile. I've also been fixing up bits of markup (for example on the add comments section) to make it easier to style.

At this point I'm still not thinking about non-typography elements such as decoration, colors, logos, etc. This part will come later (and is going to be heaps of fun).

This step took a lot longer than I thought it might, but I'm OK with that as one of the goals of this redesign is to focus on the text.

Screen Shots

SHARE: