How to name your business

You’re starting a business. You want customers. You’re going to have a website and you want people to see your site. What will you be called? Trading in the online era allows you to reach a greater marketplace than ever, but potential customers need to either know you or be able find you. It all starts with a name.

What’s in a name?

You’ve probably already spent many sleepless nights agonising over the name of your new enterprise. You found the perfect combination of words to convey the spirit of your business, but does it tell people what you actually do?

Good website names fall into two categories:

  • short and memorable
  • long and descriptive

The first category is great for word of mouth. You can tell someone the name of your business and it’ll stick around in their head. Next time they need a collectible garden gnome, they’ll come straight to you at Gnome Zone.

If you’ve got a longer, but more descriptive name you’ll find it does a lot better when people are searching for a business online that matches your name. Your potential customer goes to Google and types “buy armadillos online” (a popular search, I’m sure). The first result is the one that most closely matches their search, so your business “Buy Armadillos Online” gets their click.


Google your new name before you do anything else. What else appears when you search for your specific business name? All of these links are in vying for the very short attention span of your potential customer. If there is another business that does the same thing and has the same name (or one similar enough to be confusing), I’d advise against that name. During this search it’s well worth looking a few pages into the search results. If someone has recently set up a new site with the name you’re proposing, they may not yet be on the first page, but by the time you’ve launched your site you could have more serious competition.


URLs are important. If your business name is in your URL, you’ll rank higher when people search for your business (also, who wants a URL that doesn’t have their name in it?!). I launched my events ticketing website Ticketlab 4 years ago now. When I bought up the domain, the .com address wasn’t available, but wasn’t actually in use. 2 years later, a site appeared on the .com, confusing my search results. If you wish to “own” the name, and you think it’s a name that someone might want to use later, try and buy up the .com, the, and any others you can afford that seem relevant. There are so many domain extensions available now, you’ll never be able to own them all, but you might be able to dissuade a future rival from the name by marking your territory.


Is your business name available on social media? Setting up these profiles and linking them back to your website will give you better search rankings. Additionally, adding your business to Google’s business listings will give rich information and reviews on search results pages.

Ticketlab's Google search results

If your name has already been taken, try adding a descriptor, such as “shop”, “app” or your country to the end (Ticketlab is TicketlabUK on Facebook and Twitter).

In summary

Naming your business is one of the hardest decisions you’ll probably have to make when you start a new enterprise. All of these tips may seem like constraints on the creative process, but if you keep them in mind you’ll ensure that people can actually find you online when you’re ready to start trading.

Handy git commands

If like me, you occasionally use Sourcetree or similar Git GUI to quickly change branch, after a while you may find yourself with 200 branches in the left side, making this task a lot harder (and making you wonder why you’re not just using the command line!).

A quick remedy to this is to run:

git branch -d $(git branch --merged)

This rids you of any branches that have been merged, leaving you with a nice clean branch list.

If you then find yourself with a large pile of branches you never pushed to remote and merged (and indeed never will), you could then run:

git remote prune origin

This will remove any branches that are only on your local. Make sure you push whatever branches you’re working on first though!


Our number one SEO tip

SEO is a thorny and ever-changing battleground, and we’re always getting asked what we do to ensure our client’s sites rank for the keywords they want. As our business is mostly around the build side, our top search engine optimisation tip is not the usual content-driven response (although don’t forget to have content on your site!).

The main piece of advice we’d give – and it’s not one that will be easy to hear for a lot of people running websites out there – is that organic search is very dependent on the quality of your website build.

No matter what keywords you want to rank for, if your site isn’t at it’s best from the code up then Google will penalise you. Additionally, if your your web developer isn’t up on all of Google’s latest algorithm changes, you need to find a better web developer.

I recently had a chat with a prospective client whose existing web development agency “didn’t do SEO” and thus traffic to their site had dropped by 40% in the last month, simply from visitors who would normally find them via organic search. The issue was easily diagnosed: their site wasn’t mobile friendly, and thus fell foul of one of Google’s most highly publicised and recent algorithm tweaks.

So do make sure your code is valid – use the w3c’s HTML validator – and keep an eye on what Google look for in a website (check out the Google mobile-friendly test).

On Ticketlab, we identified our key search terms before we even started building the site, and we ensured those keywords pepper the whole site and appear at every level. As such we are number one for this particular search that other ticketing sites haven’t targeted and we attract most of our new sign-ups through these terms (which I won’t divulge here lest it dilutes our rank!).

We currently get around 20% of our traffic via organic search and it has the lowest bounce rate of all our acquisition methods (0% on traffic generated via the terms mentioned above, around 55% overall).

Step by step guide to converting your web app to an Android app

I’ve published a couple of apps to the Google Play store now, and when I came to do the same for a new app I’ve been working on, I had completely forgotten the steps involved and had to read all of the documentation again. It’s not straightforward, and involves a lot of commands in the terminal.

This as it is, I’ve resolved to document the process here so that, at the very least, I’ll be able to remember for next time. Hopefully this will help you too. Thanks go our to this article here which really helped me get to grips with the concepts (and which I’m mainly just elaborating on here).

I’m primarily a web developer, so am comfortable with the HTML, CSS, Javascript technology stack. In the last year or so, I’ve augmented this with Angular to enable rapid development of web apps.

The app I set out to make was to keep score in the word-based board game Scrabble. I built it over the course of a couple of weeks using Yeoman to create the project structure, which allows easy integration of Bower components and Grunt tasks. When generating the project with Yeoman, I opted to include Bootstrap to give me a head start on the styles, and SASS to organise and compile my CSS. At the end of development, you can run

grunt build

to minify and concatenate all files and prepare them for distribution.

Whatever your method for creating a web application, you go ahead and do it. It could just be static HTML if you feel that it makes a useful app for someone. Either way, now you have an app. Next stage is to get Phonegap involved to convert it to an Android app.

First, make sure you have Phonegap installed:

sudo npm install -g phonegap

This does have a dependency on NodeJS, so make sure to go get that. Then you’ll want to create the Phonegap project. In a suitable directory, run:

phonegap create my-app
cd my-app
phonegap run android

This creates the directory ‘my-app’ (in this case, obviously feel free to call it something that resembles your app name) and puts a whole whack of files in it.

You can now copy all of your web app files into the my-app/www directory, replacing those that had been created for their default ‘HelloWorld’ application.

Prepping your app

In order for your app to know what it is in the world, you’ll have to update a few definitions in some xml files. First up,  go through the www/config.xml file, and update all the info so it looks like your app and your details. Also in here in the ‘widget’ tag is the version attribute. This is the version number that’s displayed to users in the Google Play Store.

The other file you’ll need to update is platforms/android/AndroidManifest.xml – this contains references to your package name (which you’ll want to change to com.yourcompany.yourappname), you’ll want to add the attribute:


to the ‘application’ tag, and each time you want to publish a new version you’ll have to increment the ‘android:versionCode’ attribute on the ‘manifest’ tag. You can only go up in whole integers, and this the the version that the Play Store itself uses to recognise a newer version of your app.

Generating a keystore file

Run the following command

keytool -genkey -v -keystore my-app-key.keystore -alias app_key -keyalg RSA -keysize 2048 -validity 10000

Follow the prompts and it will create a keystore file in the folder you run it from (with the name ‘my-app-key.keystore’ or whatever you put in that bit of the command). It’s recommended not to keep this in the same file as your app, and certainly don’t put it in a public Github repository.  You should create a new one for every app you make.

Next, create a new file called ‘’ inside platforms/android in this, save the following information

the relative path should point to where you saved your keystore file, and the alias is as specified in the keystore generation command.

Signing in release mode

Run this in your phonegap project:

phonegap build android

You’ll then want to run the following, which will create release versions of the app:

cd platforms/android
ant release

Follow the prompts and enter your keystore password where required.

There will now be some new files inside the bin directory, have a look, as you’ll have to target one of them at the next stage.

To sign the files, you’ll need to head to the bin directory and run the following:

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore ../../../../my-app-key.keystore MyApp-release-unsigned.apk app_key

Where ‘../../../../my-app-key.keystore’ points to your keystore file,  ‘MyApp-release-unsigned.apk’ is the ‘…-release-unsigned.apk’ file just created and ‘app_key’ is the alias name for your keystore.

Enter your keystore password again when prompted.

Verify the signing like so:

jarsigner -verify -verbose -certs MyApp-release-unsigned.apk

Finally, you need to zipalign your newly signed file. This does some compression and optimisation and saves the file to a new name as specified

zipalign -v 4 MyApp-release-unsigned.apk MyApp.apk

I had an issue where zipalign gave a ‘Command not found’ error. This was resolved by searching for where zipalign lived on my system and including the file reference in the command e.g.

/Users/riley/Development/adt-bundle/sdk/build-tools/21.1.2/zipalign -v 4 MyApp-release-unsigned.apk MyApp.apk

This generates the final MyApp.apk file you can upload directly to the Google Play Store.

Hope this of help to someone other than me. Happy apping!

SUIT CSS practical implementation guide

SUIT CSS naming conventions

SUIT CSS relies on structured class names and meaningful hyphens (i.e., not
using hyphens merely to separate words). This helps to work around the current
limits of applying CSS to the DOM (i.e., the lack of style encapsulation), and
to better communicate the relationships between classes.

The primary architectural division is between utilities and components.

N.B: The majority of this file is taken from SUIT CSS Naming Conventions, except where indicated by an asterisk ( * ).

Anything marked with an * has been added by myself as a way to provide more detailed implementation notes.


Low-level structural and positional traits. Utilities can be applied directly
to any element within a component.


<a name="u-utilityName"></a>


Utilities must use a camel case name. What follows is an example of how various
utilities can be used to create a simple structure within a component.

<div class="u-cf">
    <a class="u-floatLeft" href="{{url}}">
        <img class="u-block" src="{{src}}" alt="">
    <p class="u-sizeFill u-textBreak">

Responsive utilities

Certain utilities have responsive variants using the patterns: `u-sm-<name>`,
`u-md-<name>`, and `u-lg-<name>` for small, medium, and large Media Query

Restrictions *

Utilities should be used sparingly in a project intended to go into production. They are there as a convenience to aid rapid development, but when used inside a Component, it’s far more useful to style an element based on it’s intended purpose. If you need to use more than one Utility to get the desired effect, then it’s less verbose to actually give that element it’s own class within the Component’s structure.

<!-- BAD -->
<div class="Component">
    <p class="u-textAlignLeft u-floatRight"></p>
<!-- Also Bad -->
<div class="Component">
    <p class="Component-bodyText u-floatRight"></p>
<!-- Good -->
<div class="Component">
    <p class="Component-bodyText"></p>


The CSS responsible for component-specific styling.



This has several benefits when reading and writing HTML and CSS:

* It helps to distinguish between the classes for the root of the component,
descendant elements, and modifications.
* It keeps the specificity of selectors low.
* It helps to decouple presentation semantics from document semantics.

namespace (optional)

If necessary, components can be prefixed with a namespace. For example, you may
wish to avoid the potential for collisions between libraries and your custom
components by prefixing all your components with a namespace.

.twt-Button { /* … */ }
.twt-Tabs { /* … */ }

This makes it clear, when reading the HTML, which components are part of your

<a name="ComponentName"></a>

The component’s name must be written in pascal case. Nothing else in the
HTML/CSS uses pascal case.

.MyComponent { /* … */ }
<article class="MyComponent">


<a name="ComponentName--modifierName">

A component modifier is a class that modifies the presentation of the base component in some form (e.g., for a certain configuration of the component).

Modifier names must be written in camel case and be separated from the component name by two hyphens.

The class should be included in the HTML in addition to the base component class.

/* Core button */
.Button { /* … */ }
/* Default button style */
.Button--secondary { /* … */ }
<button class="Button Button--secondary" type="button">…</button


<a name=”ComponentName-descendantName”></a>

A component descendant is a class that is attached to a descendant node of a component. It’s responsible for applying presentation directly to the descendant on behalf of a particular component. descendant names must be written in camel case.

<article class="Tweet">
    <header class="Tweet-header">
        <img class="Tweet-avatar" src="{{src}}" alt="{{alt}}">
    <div class="Tweet-bodyText">

<a name=”is-stateOfComponent”></a>

Use `is-stateName` to reflect changes to a component’s state. The state name must be camel case. **Never style these classes directly; they should always be used as an adjoining class.**

This means that the same state names can be used in multiple contexts, but every component must define its own styles for the state (as they are scoped to the component).

.Tweet { /* … */ } { /* … */ }
<article class="Tweet is-expanded">

Notes and recommendations *

While the above provides good guidelines on naming structure, it doesn’t deal with “What to do when…”. Here we’ll try and draw out any unusual use cases and draw forth potential solutions to these. As mentioned before, this section has been asterisked to indicate that it’s my own recommendation. Please feel free to comment on this post if your approach would differ from what has been here documented.

SASS parent selector markup

In current versions of SASS, it’s possible to use the parent selector ‘&’ to create a new class composed of the parent and a suffix. This is especially useful for our purposes as it means we can create a self-contained Component block of SASS e.g.

.Component {
    &-descendantName {
        &--modifier {

This allows us to vastly reduce the amount of SASS we need to write, while also producing classes with a low specificity. For example, the above code produces the following 2 classes, each of which has a specificity of 10 (or 0, 1, 0 if you’re that way inclined).

.Component-descendantName {
.Component-descendantName--modifier {

Components within components

As far as I’m concerned, a Component should hold majesty over all who reside within it. In much the same way as the heart is it’s own structure with it’s own function, but when it’s inside a larger corporeal being, that body determines where it resides. I’ve seen a few examples where nested components are also given descendantName selectors e.g.

<!-- Not recommended -->
<div class="Component">
    <div class="AnotherComponent Component-anotherComponent">
        <p class="AnotherComponent-bodyText"></p>

I think this is bad form, even though I can see the logic behind it. In this example, AnotherComponent may well exist in several contexts in an app, but this code specifically ties the DOM to this usage. The CSS for this is transparent enough, but I’d propose the following markup and SASS as an alternative:

<div class="Component">
    <div class="AnotherComponent">
        <p class="AnotherComponent-bodyText"></p>


.AnotherComponent {
    &-bodyText {
.Component {
    .AnotherComponent {
        &-bodyText {

In this way, Components can be used in any context (thus making their code portable and ‘directivable’ without needing to shoehorn extra classes in there), and any manipulations required due to the new context are handled by the responsible parent Component.


This approach is frowned upon – see this discussion, which revolves around the following use case:


<div class="Component">
    <header class="Component-header">
        <a class="Component-header-link" href=""></a>
        <!-- Or -->
        <a class="Component-headerLink" href=""></a>
At the end of the discussion, the most popular solution is to make ComponentHeader it’s own component within “Component”
<div class="Component">
    <header class="ComponentHeader">
        <a class="ComponentHeader-link" href=""></a>
Happy to consider alternatives as you guys see fit although double-descendants don’t frighten me personally.

Modifier and state inheritance

Modifiers needn’t just affect the direct element they’re applied to – they can also change the appearance of any nested Components further down inside that DOM tree. This could lead to some convoluted-looking SASS. Take the following example:

<div class="Component Component--modifier">
    <div class="AnotherComponent">
        <p class="AnotherComponent-bodyText AnotherComponent-bodyText--modifier"></p>

Say for example that the Component–modifier here was a theme for this component. This would change the theme for all nested components too, which means it would likely need to reach down into AnotherComponent-bodyText to alter it’s colour.

.Component {
    background: blue;
    .AnotherComponent {
        background: red;
        &--modifier {
            color: white;
    &--modifier {
        background: black;
        .AnotherComponent {
            background: white;
            &--modifier {
                color: black;

As you can see here, modifiers are placed at the end of each declaration so ensure they are always the dominant style over any given base class.

Equally, States can affect descendants as well, although it is recommended to keep the class as close as possible to the area it’s going to affect e.g.

<div class="Button is-active">
    <span class="Button-icon"></span>
.Button {
    background: black;
    &-icon {
        color: black;
    &.is-active {
        background: white;
        .Button-icon {
            color: black;

States also appear at the end of any given class definition, after any modifiers that may be applied. States are naturally more specific than modifiers (in the example above, if the Button had a modifier it would be of specificity of 10, whereas the generated class for has a specificity of 20), so this is a very natural place for them to reside in the declarative order of things.

Minimum viable product and User Stories

Once you have your team, it’s time to turn your attention to the product.

You may want to build a site that displays pictures of cats, for example. This is a simple enough brief, but where should you start? This is where the Minimum Viable Product (MVP) comes in.

You want to put your site up as quickly as possible. Every minute your site is not live, you’re losing potential customers. We need to take the concept and boil it down to it’s most basic useful implementation and focus just on that. Once it’s live we can start to see people come through and we can learn what they want while we continue development (which, apart from generating revenue, is the second most important use of customers).

The User Story

So what’s our MVP for the cat picture site? What does our user want and how does that translate to development? This is where we turn the project on it’s head; we no longer have to consider why we are building the product, but rather ask the question “what does the user want to do with it?”.

As a user I want to be able to see pictures of cats so a can feel warm and fuzzy.

This is the basic format for a user story. It has a protagonist, in this case the  user but it could equally be another type of consumer of the site such as an administrator or even occasionally a developer. It also has a goal and a driver behind that goal. The goal could be psychological as in this case, or practical and it always fulfils a need – there’s very little point developing for nice-to-haves.

In order to fulfil our MVP we don’t need any design, we don’t need extra pages, we don’t need any data from the back end. We just need a single Web page that displays cat images.

Once we understand this, we would usually start to further distill this into developable tasks. Because I’d like to dedicate the next blog post to task breakdown, we’ll keep it simple. Our front end developer sets to work and adds cat images to a web page.

It probably looks a little like this:

Cat Site v.1

Sure, it’s not pretty, but now you can release your site to the world, safe in the knowledge that people can look at cats.

Next up: Task breakdown.

Working as a team to deliver software

Team organisation

In order to build a successful web app, you need to have team representation from every discipline. These disciplines are:

  • Information Architecture
  • Design
  • Back end
  • Front end
  • QA

This list is largely representative of the functions needed to produce any other piece of software (mobile app, desktop app, game), which can be augmented or substituted with additional members as need be.

Incidentally, this order is approximately the order in which you need to tackle a piece of functionality in order to complete it.

The importance of role separation – even in small teams

While it’s possible to have a single person be responsible for more than one of these disciplines, I would still recommend they are treated as separate and approached as different tasks. This prevents you from needlessly switching between multiple jobs, damaging your efficiency. It also means you’re 100% focussed on the solution at hand, which should yield better results.

By breaking work down into component disciplines, you can start to simplify the load. This prevents generating or tackling too much work at once (which is harder to then analyse and digest by the team). You can also start to assign jobs to different people. By splitting the job out between multiple team members we can increase our pace, but at the expense of continuity of information. This sounds obvious, but if you’ve spent a year working on a project in a closed room on your own, then you really need to stop and readjust your way of thinking to incorporate the concept of ‘team’.

The process I’m trying to outline here is designed to minimise the extra overhead incurred from using multiple team members on a project.


Aside from actually delivering your software, continuity of information should be the top priority for your team.

Your team is dependent on all other members in order to deliver (as the array of disciplines should indicate; you can’t do front end without design, for example). Equally, should a team member fall sick or leave the project, then the others will know what they were working on and be at least able to account for what part of the puzzle is missing (even if they can’t step in to their role personally, they could impart knowledge to a new-joiner).

Ideally, your team should communicate on a daily basis in a stand-up or scrum. In these meetings each member says 3 things :
– what they did yesterday
– what they’re doing today
– any issues, impediments or blockers to what they’re doing that another team member may be able to alleviate.

Talentomic is being co-developed by myself and another developer based in Helsinki, which makes it a great example of the need for constant communication. As progress happens around other commitments and work, we both have a different pace of working – I may have 4 hours free in a given week, whereas my counterpart may have 30. It’s thus unproductive for him to be waiting for me to complete something, or if he is dependent on me to deliver something, knowing it’s precise status helps plan his work and keep the project moving.

Once your team knows who they are and what they’re trying to achieve, it’s time to start breaking down the project into bite-size chunks, which will be the subject of my next post.

Planning and delivery for medium sized software projects

I intend to put together a series of posts over the next few weeks on my learnings and views on delivering software. I will be using concepts mostly pillaged from others at the various places I’ve been working over the last few years who are or claim to be ‘agile working environments’ as well as from things read online (sources I’m very unlikely to remember, so please excuse me).

This will largely be advice garnered from and intended for practical application – there are many tomes dedicated to theoretical agile delivery, but this should act as a good beginner’s guide and provide templates that can been lifted onto your own software challenges.

By ‘software’, I mean any form of incrementally deliverable product. I will be predominately concerned with Web apps, but with practices that could as easily be used for mobile apps, installable computer programs (providing you have functionality to update them) and games.

At Ding Digital we’re in the process of creating a talent management application called Talentomic. I will pepper this guide with working examples from this work to provide context which I will also be able to show in the various stages of its delivery.

The first section is all about The Team and can be found by going to the next post.

Building a web page from an InDesign file

There are an increasing number of articles around about how to design websites using InDesign. In theory (and according to the logic of these articles) there’s nothing to stop you designing a web interface in InDesign. In fact, there are some reasons why it’s almost more suited to web design than Photoshop: the ability to keep multiple pages and layouts within one file, the smaller filesize for holding all of those layers.

That being said I’d still never advise InDesign as the tool of choice. If you take a reasonably simple layout such as the one I was given for social discussion platform Pressr and use InDesign’s own Export to HTML functionality you end up with a complete mess.

Pressr Homepage in InDesign  HTML as exported by InDesign

Don’t forget we are looking at software built for print design here. To all of those people, organisations and blogs instructing in how to design for the web in InDesign: stop.

So, here’s the real problem: you’ve been given an InDesign document and you need to make a web page from it. What’s the best way? Previously I’ve faced this problem by exporting the layout to Photoshop as a flat file (PDF or even just screengrabbing it) and working on it as usual.

Here, we assume you have a good working grasp of HTML and CSS in their most recent guises.

Step 1: Export to HTML (to get your images)
Yes, I know I’ve already said the results of this are pretty dire, but what InDesign does do well here is export all of the images you need and at the correct sizes in the right formats. It knows when a PNG is better suited than a JPEG – usually based on the source of the image (an AI file in your layout will be saved out as a transparent gif, a photo makes it out as a jpeg). I did find my images came out twice as large as they were in the design – I’m not sure if this is due to the document set up or something else in the file – but you may need to open these in photoshop and resize them.

Step 2: Get your text
You may find it’s easier to copy the text from your design from the HTML file created in the previous step before you discard it – it’s no picnic to select every text box within a layout and copy the text.

The other method of selecting and copying all text in an InDesign document is to use a script found at Application > Samples > Javascipt > ExportAllStories – this exports every text area as a separate text file, which creates it’s own problems.

Step 3: Start coding
So, you have all of your text in one document and a handy directory full of images, now you need to layout the structure of your HTML document. First up, I recommend downloading a copy of the HTML5 Boilerplate as the basis for your HTML. It’s a solid start, but you might find some parts unnecessary for your project – I rarely use Moderizer on small projects where the HTML will be mostly flat for example. At the very least you’ll a need DOCTYPE, a head (containing your empty stylesheets) and a body. If you don’t have a head or a body I wonder how you hope to do anything in life.

At this stage it pays to layout all of your text (including headers, navigation and footers) on your page in the order that is most logical for it to appear. What you’ll make here is a document without styles that shows your text in the right hierarchal order. In the case of our Pressr design, even though the hero image and that quote are first in reading order, if I were looking at this without images, I would probably want the main text to appear first. This is simply based on what’s most important on the page and without the user having to scroll. If this page is also to be responsive then I image mobile users would have a lot of scrolling to do if encountering that image first, so let’s just start with the main copy.

Wrap your text and divide it into sections using the appropriate tags. Your header should be in a header tag, your footer should be in a footer etc. You can see my Pressr HTML layout at this stage if you like. Notice I’ve placed the main content in a section tag and the image and quote in an aside tag. Sections are often used as a replacement for a div, although this is incorrect usage according to the spec – they should be used for content that could be considered stand-alone i.e. if placed on another page would still make sense on it’s own. Asides are used for content related to the current page, but not necessary for understanding it, hence my usage here. When viewed in the browser at this stage without styles, this is what you get:

Screen Shot 2013-11-18 at 07.35.57

I could leave it at that really – Google would be happy with it certainly – although the client may complain.

Step 4: Get some style
Depending on the size of your project you may want to use a CSS preprocessor such as LESS or SASS, or you may want to employ a framework such as Bootstrap to give you a head start.

Personally I tend to find frameworks are more useful if you are prototyping and need elements with pre-defined styles so you can just add a class and forget about the styling for a while. This design is pretty straightforward and we only have a handful of pages (all similarly styled) so I’ll just be coding my CSS from scratch.

I will include a CSS reset (everyone should), but otherwise we’re just going to get stuck in.

Your main ally in InDesign is the Window > Info panel. When you click an image or layout rectangle it’ll tell you the width. This is assuming the designer built this to web specs and using pixels. If not, you may still have to export and open in photoshop in order to resize the design to a suitable size and find out the sizes you’ll need!

If you want to find the colour of an element simply click it and double-click the colour swatch in the left hand tools menu – this will give you the RGB colour. If you’re keen to use the hex value, then you’ll either need to convert it or you can find the value in the Character style palette as detailed in this article.

The finished product can be seen at