Skip to content

Latest commit

 

History

History

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 

Week 14

Today, Friday 6th May 2016

  1. Prototyping with HTML&CSS
  • HEADS UP! Next session will be Tuesday 17th

Your homework and blog!

Browser-prototyping

The web-design process

According to Matteo (and many others):

  1. Research and content strategy: gathering information and thinking through information architecture, navigation and typography
  • Sketches and wireframes: exploring ideas for layouts and content structure
  • Prototype: creating 2–3 key pages using HTML & CSS. Much of the design process happens here
  • Development: building the site (e.g. with WordPress) and refining the design

The difference between a good site and a great site is iteration — building something, playing with it, refining it.

This iterative process helps me refining ideas and focusing on one thing (usually the appropriate thing) at a time. I like starting with type, grid and layout, then add colours and images.

Here's an example

From BlankBox, a coffee subscription project I worked on a couple of years ago (sadly not operating anymore):

  1. Design (a bit of) content strategy + wireframes on paper

  • Prototype with HTML + CSS using Bootstrap (a front-end framework, more on that below) and iterate

  • Build the product (with WordPress + many plugins) and test it with real people

  • Back to the drawing board...

Why prototyping with code?

What about Photoshop?

Photoshop (and similar) allows you to create static mockups but doesn't let you design the states of an interface: how does your layouts reflow and adapt to different screen sizes, how do interactive elements respond to click touch and other events?

This is dangerous, as you may end up with an artist's impression of a Web page, rather than designing the complex, dynamic thing which is a Web page.

A Photoshop mockup needs to be interpreted (by the coder translating it into the real thing) which can lead to a lot of inefficient and unnecessary back-and-forth.

HTML + CSS prototypes instead...

Responsive

Because they're built with code and you can test them directly in your browser, HTML + CSS prototypes are better at demonstrating responsive behaviour.

One of the biggest challenges in Web design is the huge and constantly growing number of device screen sizes (here are 286 common ones).

Would you design 286 different mockups in Photoshop?

Accurate

HTML + CSS prototypes can give you (and your clients) an accurate representation of the way your product will really look and function.

For example, fonts often look slightly different across various browsers than in Photoshop (and similar). This can cause delays and confusion among clients, who often expect your product to be a pixel-perfect match to mockups. See Make it like the PSD!

Consistent

HTML + CSS prototypes reduce the chances of errors and inconsistencies.

CSS enforces consistency across your design (for instance, applying the same margin to all your paragraphs). Making changes is quick and efficient.

Photoshop... well, try and change all those buttons from red to green.

Catch real issues, early on

HTML + CSS prototypes allow to catch potential issues before they become real problems.

This provides an early opportunity to adjust how your product works, rather than waiting until front-end development is completed.

Save 🕦 and 💰

In essence HTML + CSS prototypes can save you time and money.

Your product will be viewed in a browser so it makes sense to use the browser (and its native languages) early on in the creative process, doesn't it?

How to prototype with code?

Browser-prototyping is about translating your wireframes into HTML + CSS.

Starting from scratch is not quick. Better to use a framework like Skeleton or Bootstrap to lay the foundation of your prototype.

Skeleton is easier to learn, Bootstrap is more complex but also very popular and has lots more hackable themes and tools.

Meet Bootstrap

Originally designed by Twitter for their own prototyping, it’s become the most popular HTML, CSS, and JS framework for developing responsive, mobile-first projects on the Web.

Available to everyone for free!

Let's do it

We're going to prototype a couple of pages using Bootstrap

Tools you'll need

  • A browser: Chrome or Firefox (not Safari or IE)
  • A code editor: Brackets or Atom
  • A Bootstrap builder: there are several, we're going to use Pingendo

Step 1: assemble the building blocks in Pingendo

Keep in mind that prototypes are not about the final look and feel. You want to keep them unfinished and focus on real content and navigation.

Using Pingendo assemble the main building blocks of your page: navigation, headings, buttons and paragraphs.

Save your page (the homepage is conventionally named index.html).

Don't worry if your prototype doesn't reflect your wireframes at this point. You will tweak it later in the code editor.

Step 2: inspect it in your browser

Open your page (eg index.html) in your browser.

We're going to use the browser's built-in Web Inspector to see what sort of code is behind the prototype we just fleshed out.

Did you know, you can see the code behind every site on the Web? You can use the Web Inspector to do this. It's like x-ray specs for websites.

Right-click anywhere on your page, then select Inspect (or Inspect Element in some browsers).

On the left panel of the Elements tab you can see all the HTML code for the page you're inspecting.

By clicking on an HTML element you'll reveal all the CSS applied to it, on the right panel.

  • You can turn CSS properties on and off by clicking on the checkbox next to them.
  • You can also edit CSS properties by double-clicking a property and then typing in a different value.

You can also change the way any website looks (but don't worry, your changes won't affect how other people are experiencing that site). 😱

Learn all the advanced stuff you can do in the Web Ispector!

Remember: the Web Inspector is likely the most important tool in your Web-dev toolbox. Make friends with it.

Step 3: tweak it in your code editor

We're going to use Brackets for this step (Atom should work equally well, but I can't guarantee it has the same tools).

In Brackets, open the folder where you saved your page. Open the whole folder, not just index.html.

First, clean up the code to make it easier to read:

  1. Install the Beautify extension from File > Extension Manager...
  • Edit > Beautify

It's good practice not to mess around with the Bootstrap source (or any framework's source) but rather keep your changes in separate files.

  1. Create a new CSS file to store your own changes to the prototype.
  • Make sure you include the new CSS file in the head of your HTML file, like so

     ... existing head code
     <link href="matteo.css" rel="stylesheet" type="text/css">
```

Now you can start making tweaks to your prototype, both in HTML and CSS.

Pingendo will automatically pick up the changes you make in Brackets, and viceversa.

Keep the Bootstrap manual open and look up how its components work.

Tutorials

Content + wireframes

  • Is anything important missing from this page?
  • Is the most important content the first thing you notice?
  • Is there anything on this page that shouldn't be there?
  • Do you know what all of the elements on this page are?
  • Can you get to all of the major sections of the site from here? Should you be able to?
  • Do all of the labels make sense?

Homework

Keep prototyping

Prototype up to 3 HTML pages. If your project has less than 3 pages, show different states for a page, eg: before and after submitting a form.

Prep formative

Here is a checklist of what we want you to present during your formative on Tuesday the 17th.

Blog

Choose one of the following Web design myths and blog about it.

  1. People don't scroll

  2. White space is wasted

  3. Design has to be original

  4. Graphics will make a page element more visible

  5. The homepage is your most important page

  6. Design is about making a website look good

Questions that could guide your blog post (in no particular order):

  • Where do you think the myth you chose may come from? Eg: why do some people believe that users don't scroll webpages?
  • Where did you hear about this myth?
  • If you feel like it isn't a myth, what are the reasons?
  • What are alternative ways to approach the design problem that the myth addresses?