CSS Calc: Creating fluid layouts with more precision

Recently I have been using the “calc()” css property to add more precision to the fluid layouts I’m working on.

If I wanted a combination of fixed & flexible width columns incorporated into my designs, I can simply use “calc()”. In the past, creating this layout was highly difficult, but this has been made easy with “calc()”.

fixedAndFluidTwo

First, You set up the width of the fixed column, then you make the width of the fluid object 100%, then you subtract the styles that make up the total width of the fixed width object.

.fixedWidthElement {
  width: 200px;
  margin-right: 2em;
  float: left;
}

.fluidWidthElement {
  width: calc(100% - 200px - 2em);
  float: right;
}

View the working example here


The “calc()” css property has a great range of support across all browsers, as you can view here.

To make sure you have all browsers supported, you can install Modernizr, which detects HTML5 and CSS3 features in the user’s browser. You will want to manually add the “css-calc” detection, which is under the “Non-core detects” drop down. Click here for a link to the custom build of Modernizr.

/*=======================================
Fallback for browsers with no support
=======================================*/

.fluidWidthElement {
  width: 80%;
  float: right;
}
.csscalc .fluidWidthElement {
  width: calc(100% - 200px - 2em);
}


Building for mobile first

What is a mobile first approach?

Instead of creating a website for the desktop first, then scaling it down for mobile devices, we should embrace the constraints of mobile first and enhance the desktop design in a later stage. This allows us to address common issues with legacy browsers and help remove bloated CSS code.

Mobile First - Desktop Last


How does organizing Mobile First CSS benefit legacy browsers?

During my R&D ( Research & Development ) on a Friday afternoon, I started experimenting with organising my CSS in a Mobile First approach, which consists of writing the mobile base styles first, then implementing the Media Queries to change the layout based on the screen size for larger devices.

  • The Base CSS will target: Mobile ( + Legacy browsers )
  • The Media Query CSS will target: Tablet, Laptop, Desktop ( Supported by modern browsers )

Note: CSS ( Cascading Style Sheets ) are read by the browser from top-to-bottom, if the browser doesn’t support the code ( eg. Media Queries ), it will ignore those styles.

By creating our Mobile First CSS, we have created a layout that will work well on legacy ( older ) browsers, without having to bloat the stylesheet with additional CSS to fix specific browser layout issues. These browsers, such as ie6-ie8 don’t support media queries, so they will be served with a minimal, but usable layout based on the mobile view.

The following diagrams and CSS code snippets show how to setup the Mobile First CSS approach.


Base CSS – Fluid Layout

Our Base CSS ( Fluid Layout )

/* ===============================
Base CSS
=============================== */
.exampleClass { width: 100%; }

Note: The class / property above is an example and won’t create the illustrated layout.


Media Query CSS – Responsive Layout

Our Media Query CSS ( Responsive Layout )

/* ===============================
Media Queries
=============================== */
@media only screen and (min-width: 500px) {
.exampleClass { width: 50%; }
}
@media only screen and (min-width: 850px) {
.exampleClass { width: 540px; }
}
@media only screen and (min-width: 1500px) {
.exampleClass { width: 75%; }
}

Note: The class / property above is an example and won’t create the illustrated layout.

The key difference here is the use of min-width rather than max-width. The best way to understand this is by getting stuck into the code! So get started.

Resources

Ringing out the red – making the most of the Boost blog

Having a blog is a very effective way to get exposure and build your brand.

Your blog gives you a chance to share your work in a more in-depth and meaningful way. You can share your process, your knowledge and constantly communicate and grow with your community.

If you’re going to have a meaningful presence it should not only contain great content, it should also look great.

About 2 months ago our MD, Nathan came to me and said the current blog design needed to be less red. I sat at my desk and looked at it for a good while. A simple cosmetic change wasn’t going to be enough to mend this broken heart. I decided what the heck, I’m going to completely redesign the Boost Blog.

The old tomato once known as the Boost blog

The old tomato once known as the Boost blog

Any spare time my developer colleague Sam and I had was spent working on the new blog design with a focus on:

  • Readability
  • Responsive design
  • Highlighting Boost’s biggest asset (our team)

To make our blog a more readable experience I threw away the alarming amount of red and instead used color to draw your eye, highlight and show relation between the elements. I focused on subtlety and slight tonal differences (your eyes can relax now) to create a design that is much more calming and approachable.

Our blog is now fully responsive to work on any browser width, with a focus for mobile, tablet, desktop and also those with an abnormally large bowser window.

A blog post in mobile view

A blog post in mobile view

We also wanted to highlight the hardworking and passionate Boost team by giving each blog author a profile image and small work bio ( these will drop down when you click on their beautiful mug’s) to make the blog just a little more personable.

I am really happy with the new blog! I believe we’ve created something pretty… well, pretty.

We hope you enjoy the new blog and we’d love to hear your feedback on it via the comments! : )

What does Lego and building high quality software have in common?

All the way from Poland and after a stint with NZ Customs, the Lego blocks we ordered a while ago are finally in our hands and we’re very excited.

Lego

For those of you who have already been on the Intro to Embracing Best Practice workshop that we run, you’ll recall that we mentioned several times that some key concepts around building high quality software could be demonstrated very easily and in a very tangible way, if only we had some Lego. Who’d have thought building high quality software and building Lego would have shared so many similarities? :)

Well now the Lego is here and we’re ready to get down to some “serious play”. During our next Intro to embracing best practice workshop we’ll facilitate a hands on demonstration of the Agile concepts of Test Driven Development (TDD), Refactoring and Continuous Integration (CI). Our aim will be to facilitate your understanding of why these concepts are so important to building high quality software whilst enabling you to continue to be leaner and faster. Best of all, you’ll be building Lego, not writing software.

The next Intro to Embracing Best Practice workshop will run on February 14th 2014, you can book your place here.

However, if you can’t wait that long, or you’ve already been to the workshop, why not get in contact with us and we’ll run a special session for you. Email us at [email protected] or give us a call on 04 939 0062.

The new Boost website is live

You may have noticed a bit of extra colour has crept in to the Boost website recently. After just over a year of refining our content and finding out exactly what people wanted from our site, the time has come to apply the design.

It’s always difficult for a company that designs websites to create their own, but in the end the Boost site came together surprisingly easily.

These are the steps we undertook when designing the site:

  • Created a simple, modular site
  • Iterated the user interaction design
  • Created moodboards
  • Designed the website directly in the browser
  • User tested the site’s interactions

As you may be aware we were approaching the new site build in the same way we like to approach all our design work, in an Agile way. We start by making a very basic, modular site. We don’t do any design up front and focus on getting all the content and functionality we want in place, along with the user experience (UX) and site structure.

boostsite1

The designers are heavily involved in this process, and by the time it comes to actually creating a look and feel for the site they are already fully immersed in the project and can make much more informed decisions.

We began the design process by creating a moodboard. Our two designers collaborated to gather elements so we could decide on a direction that we wanted to take. These elements included examples of typography, colours available to us from the Boost palette and a range of icons the designers liked.

boostmood2

The team have been very excited to further progress the site so that we now have a design that represents Boost. Michael Trilford (who has been a designer at Boost for 7 years) said “I have been waiting 6 years to redesign the Boost website, finally the time has come to go live, Bliss!”.

The enthusiasm they had for the project was obvious, they pair designed the site directly in the browser. The introduction of web fonts and icon fonts allowed them to skip the extensive Photoshop aspect of building a website. Jesse, the developer on the project, collaborated with the design team daily to ensure that their ideas became something that could work, and work across platforms.

boostmood3

By doing it this way, they could then be confident that every pixel was aligned correctly on the baseline grid, which in turn created a great vertical rhythm and mathematical harmony.

We also sent out an IntuitionHQ test to check that the navigation was making sense to people. We followed up our online testing by doing some in-person testing so we could observe how participants were interacting with the website and where they were having difficulties. We are compiling the results of these tests which will inform future enhancements.

Speaking of which, we plan to keep evolving the site over time. So leave a comment if you have any feedback as it is very valuable to us and will be taken on board when we are planning future sprints.

The Boost website evolution

It has been a while since we last posted an update on the progress of the Boost website. There have been many additions since then, and there are a few radical changes just around the corner, so it feels like a good time to talk about where we’re at now.

We’ll be talking about the following features today:

  • Boost blog enhancements
  • Landing pages for mobile and app development
  • Adding Rally as a partner
  • Including Boost Jelly on the homepage
  • Content restructure
  • Adding an about us page
  • Our internal Scrum

Boost blog enhancements

The sidebar on the blog was getting a little unwieldy, so we decided we needed to tidy it up. Gone were the months listed out in the archive, in came the years, with a post count beside each one. This gave us a lot more space where we could then list out the categories, again with post counts beside them.

These changes may seem minor, but have made it a lot easier to navigate through our previous posts.

Landing pages for mobile and app development

We wanted to advertise some of our services, and chose to do so on Google and Linkedin. These ads were specifically about Agile Coaching and Mobile App Development, so we felt the need to have landing pages that dealt only with those services.

Unbounce gave us the opportunity to get these landing pages up quickly once they were designed, and allowed us to track conversions with ease.

Once a user lands on one of these pages, they need to enter their details to download the case studies we had put together, making these very meaningful leads from our perspective.

landing

Adding Rally as a partner

Boost has partnered with Rally, who offer Cloud-based solutions for managing the Agile development lifecycle, and we find their principles closely align with our own. You can now see their logo and a little bit of information about them in our sidebar.

We now use the  Rally software to manage most of our Agile projects, and the features it provides make it suitable for small projects all the way up to Enterprise level projects.

rally

Boost Jelly

We love having people from a variety of interesting industries come in each Friday and use our workspace (and our Wi-Fi and coffee machine). It’s always fascinating to have someone completely unrelated to Boost set up and work amongst us for a day. We noticed that no one had arrived for a few Fridays in a row, and realised that we needed to add Jelly back to our homepage so people were aware that it was still an open invitation. We hope to see some of you here soon.

jelly

Content restructure

As Boost has evolved our focus has shifted from pure website development to web and mobile application development. We cut back on the homepage content and rewrote what remained to reflect this change.

We removed all of our Agile Coaching content, as that now has a home at boostagile.com, and gave more prominence to Boost Agile in the sidebar so that visitors can still find it. All our workshops and courses are now listed under the Boost Agile umbrella.

About us page

We finally have an about us page. With all of our homepage content devoted to our services and our work, we needed to  find a place where we could give a little bit more background about ourselves and provide a more extensive list of the clients we have worked with.

about

Our internal Scrum

We like to practice what we preach, so all of our internal projects are run using Scrum, and the Boost website is no exception. We try to keep the team who work on the website as stable as we can, and they are now a close-knit and truly self-managing group.

retro

Our retrospectives have consistently brought up interesting ways to improve a variety of aspects of the project, and the enthusiasm and openness of the team have kept the momentum going.

We are happy with the website in terms of content, and the next stage will be unveiled very soon. We are pretty excited about the work coming out of the current sprint and keen to let everyone else see it too.

5 steps to better value for money in web application development

No one wants to be the next Novopay! How do you ensure good value for money in web application development? It’s a question we are often asked and doesn’t have a straightforward answer. In this post we will look at some of the techniques we use to deliver better value for money on our projects.

Customer and team collaborate at every stage

To ensure that the vision held by the customer is shared, the customer and team must collaborate effectively and efficiently. Using good facilitation tools and techniques, and agile ways of working, the customer’s vision is clearly shared by the team and enables them to make sound decisions at every stop of the way.

Get fast feedback from the market

Key to getting good value for money is getting feedback from your market early and often. Working to get the application to market as early as possible reduces risk by ensuring the feedback loop from clients is as short as possible and by reducing investment before feedback. Integrating customer feedback into your development process will ensure that the features being developed are of value to your customers.

Build quality in to reduce the cost of change

Following technical best practices such as BDD & TDD is an excellent way to ensure quality is at the forefront in development. Technical best practices reduce the number and severity of defects in the work which frees valuable resource for creating features. The cost of finding and correcting defects grows quickly, so early discovery and re-mediation is key.

Prioritise the highest value features first

By focusing on producing the highest value features first you will ensure that the product is viable at the earliest possible stage. This ensures that the return on investment is as high as possible.

Inspect and adapt your product, processes and tools

It is absolutely essential to continually and rigorously inspect both the software being created and the way the team is working to create the software. We use agile processes to ensure that the team and client work together to improve on a continuous basis. The result is a high-performing team that is continuously improving, adapting to change and providing more and more value.

All of these ideas are supported by Agile and Lean and we are in a great position today where we are able to stand on the shoulders of giants who’ve discovered pragmatic solutions to the problems of software development.

We would love to hear your your point of view, what has worked for you in the past?

Boost Website progress

We are still working behind the scenes on the Boost website and another sprint has come to an end, bringing with it a few more changes.

This week we’ve made one change to the Boost site, some changes to the site that houses our event’s bookings, and furthered our concept for the Boost design portfolio.

View the Board’s latest episode

In our last post we talked about the Boost TV channel on livestream. We air a live show called The Board, where we talk about all things agile, every second Thursday.

Two shows have already been aired, so we thought it was time we made them easily accessible from the Boost website. You can now click through to the latest episode directly from the sidebar on the homepage, and if you are viewing it on a smartphone you’ll find it under our events information.

Eventbrite

We are going to allow event attendees to book directly though our website in the near future, but until then Eventbrite handles it. Whilst they do a great job, we felt the jump from the Boost website to their page was a bit jarring due to the differences in colours used and the placeholder images that are displayed alongside each event.

We have replaced these images with Boost branded ones, and used similar fonts and colours to our own website, which in turn makes the transition feel a bit more seamless.

Portfolio concept

We had a story in the last sprint to come up with a concept for displaying Boost’s design work in an interesting way. There was no implementation necessary, so we showed a hand drawn concept at our sprint review. We can’t say too much about it now, as it’s still a work in progress, but our next step is to create a working prototype which we can show to the team here at Boost.

If they like what they see, we will design and build the portfolio, so expect an update on that soon.

Scrummaker: The project kick-off

On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool to support teams to run Agile retrospectives, which we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.

A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.

As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.

The project kick-off

We kicked off our two days of development with a full team meeting starting at 9am sharp – all under the keen gaze of our documentary team.

Vision

Nathan outlined his vision to build a tool that would support Scrum teams, both co-located and distributed. By the end of the two days, Nathan told us, he wanted to have something ready to take out and show to people as the next step in validating this potential product.

Nathan then introduced the product backlog and read out the first three user stories and their acceptance criteria.

Team charter

Next, Paul, our Scrum Master for the project, lead us to create a team charter – an agreement on how we wanted to work together as a team for the two days.

Team charter for the development of Scrummaker

Team charter for the development of Scrummaker

Format:

  • Half-day sprints
  • Retro at lunch time
  • Retro at end of day

Teams:

  • Three teams (there’s 17 of us)

Communication:

  • If you have a problem – put your hand up
  • Be respectful of each other
  • Everything done face to face
  • Pro-active communication between teams.

Definition of done

For the purposes of the two days, ‘done’ meant:

  • Cross-browser tested (IE8 and above)
  • Technical debt reduced
  • Merged to master
  • Passing tests (full coverage)
  • Internationalised
  • Deployed
  • Metrics in place

Split into teams

We shuffled ourselves into three teams, dividing up devs, designers and UX/content people. Nathan then handed out a story to each team, and we reshuffled a little to suit them, allocating more devs to the first (and largest) story. Once we had our teams we moved into three different parts of the office, tasked up our stories and started our story boards. At about 10am, we all kicked off our first sprints.

The next two posts will cover what we learned from our two-day experiment, and Nathan’s over all thoughts.

Scrummaker: The technical discussion

On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool to support teams to run Agile retrospectives, which we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.

A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.

As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.

Scrummaker: The technical discussion

At the end of the day on Wednesday, the team met (for strict 30 minute timebox) to thrash out technical decisions we felt we needed to make in order to get off to a clean start on Thursday morning.

We grabbed post-its and had two minutes to scribble down the things we wanted to discuss. These went up on a sheet of paper, were quickly grouped, then we dot-voted to pick what we wanted to discuss the most. We agreed to spend 8 minutes discussing the highest priority item, and 4 minutes on each of the other issues, until we ran out of time.

Post-it notes with topics for our technical discussion

Post-it notes with topics for our technical discussion, grouped in priority order

The highest priority post-it was How do we avoid design blocking work. Balancing the needs of Scrum and design is something we’ve worked hard on for several years now, so it’s not surprising that with a two-day development period this came to the fore.

After discussing the issue, we came up with a series of actions:

  • Collaborative wireframing to kick each story off (then being able to start work on dev and design concurrently)
  • Use the Foundation framework from Zurb
  • Pair programme to implement design
  • Start with very basic design, and finesse later
  • Not use any text in images (this is also in the interests of internationalisation)
  • Use Sass

It turned out that this discussion also knocked of the second-highest post-it, CSS framework, so we moved on to Integration. Here we agreed that:

  • Master always has the working product on it; development is done on feature branches and then merged.
  • We’d set up a CI server, a Git repository, and use Cloud Climate, Semaphore, New Relic and Airbrake.

Next we quickly covered off Testing, agreeing to stick to our usual practice of Behaviour Driven Development, and to use RSpec and Cucumber

The Hosting post-it got the one-word answer Heroku.

JavaScript was up next. We knew that Scrummaker was going to be heavily interactive, and that JavaScript would be very important. We agreed on Unobtrusive JavaScript and that we’d discuss this in further detail on the day as it came up.

Finally, we agreed on a zero critical bugs policy – new development would always come second to fixing critical bugs in existing features.

At the end of half an hour, we felt prepared for the project kick off at 9am the next morning.