Tag Archives: code

Emma Barnes: embrace the code


This is a guest from Emma Barnes.
Emma is m.d. of Snowbooks, the independent publishing house she co-founded in 2003, and c.e.o. of the FutureBook-award-winning Bibliocloud system for publishing. As both a publisher and a coder, Emma has a unique vantage point on the intersection between digital technologies and innovative content.

When I graduated with an archaeology degree in 1996, and got a job as a management trainee for a global retail group, I had no idea that 8 years later I’d co-found an independent publishing company. And when I co-founded that independent publishing company, I had no idea that,13 years further on, I’d find myself a professional Ruby on Rails developer.

Life is weird. And you can’t plan it out. All you can do is try to be happy, and learn as much as you can on the off-chance that it’ll come in handy. I’ve got lucky: not only do I run Snowbooks — a lovely little publisher of amazing books — but nowadays I’m the lead programmer of Bibliocloud, our title management software which we’re formally launching out of beta at the London Book Fair this year.

A decade of steadily automating away the administrative drudge of publishing has left me a proficient programmer: first in XML and XSLT and now in the tools of the web development trade: Ruby on Rails, jQuery, SQL, HTML5 and CSS3 and database management on PostgreSQL. Using these tools, with my team, I’ve built Bibliocloud to be an enterprise management application which takes care of almost every aspect of our business. Snowbooks has relied on Bibliocloud throughout the app’s development: at the end of 2012 we started to license its use to other publishers and organisations.

Starting to code was not a frightening step into the dark, because I took baby steps. In 2003, I opened up an ONIX file. ONIX is XML, written more or less with English words. Figuring I could use it to populate AI templates, I tinkered with manipulating the XML until that was second nature. Coding is very moreish — start down the road, take small, incremental steps. Let the years pass and before you know it, you’ve got your 10,000 hours under your belt.

You shouldn’t think that you could never learn to code. My mental arithmetic skills are worse than my 6 year old’s. I would have been laughed out of a computer science degree interview. But I love patterns, and stories, and brevity and elegance: all the things that publishers are good at. You don’t know whether you can do it unless you try.

I learned to program because I needed something like Bibliocloud to exist so I could run Snowbooks properly. No-one else was going to write it, so I tooled up and did it myself. I had to go from a standing start, skills-wise, so it did end up taking quite a few years to progressively learn the right skills. But now I’m at the other end of the journey, it’s interesting to be able to compare life without coding skills, and life with.

And life without coding skills is awful! It’s chock-a-block full of admin. No-one goes into publishing to spend their days filling in repetitive, endless spreadsheets, surely? But unless you can manipulate data throughout your working day with little programs, you’re tied to the manual way of doing things.
If you can’t code, you don’t know what you don’t know. You don’t know what’s possible. You can’t be a digital creator because you’ve got no tools at your disposal, and no understanding for collaborating with others on such projects.

Only a select few publishers employ programmers at the moment. This will change, and the change will be overnight — but it takes time to learn how to code, so start now, or the new jobs will go to outsiders. Nowadays there are some amazing, cheap ways to learn programming — because people who can code are passionate about sharing their skills with everyone else. Look at Codeschool. Come to our own course, Try Programming for Publishers. Read The Rails Tutorial by Michael Hartl — by the end of it, you’ll have written your very own version of Twitter. Imagine!

In seven years, the kids who are currently learning to code in school, as part of the national curriculum, will be graduating. People with all sorts of degrees will have coding literacy, a skill as basic to them as English and maths. You’ve got a seven-year head start on them. Start to learn code now and you won’t be skilled out of the market before you’re 40.

Emma is on Twitter as @bibliocloud

Leave a Comment

Filed under Industry Voices

Good HTML etiquette – the accessible link

Still with me for Part Three? Huzzah. Hopefully, you have all had a little bit of a practice with everything we’ve talked about so far.

Part One – why HTML?
Part Two – the building blocks of HTML

With the basics hopefully making sense, it’s time to get a little bit more sophisticated. But not too sophisticated, so don’t worry. Some of what I am going to talk about relates to accessibility, some of it is because that is just the way computers work and it would take far too long to explain. Just accept that this is the way it should be done!

Firstly, accessibility and why you should worry about it:
Accessibility is about making your website (and content) accessible to all users, regardless of ability, and regardless of what browsing technology they’re using. You need to keep in mind that not everyone views the Web in the same way that you do. They might have a desktop with a huge screen, or an old one with a tiny monitor, a laptop, an iPad, a mobile device, a TV… They might be blind or partially sighted, or their mouse might be broken, or they are stuck on a dial-up (or dodgy mobile) signal that is sloooooooooooooooooow to load. They might even be a screen-reader, or a text-only browser such as Lynx.

By making your website accessible you are opening it up to a much wider potential audience. Making something accessible for humans also has the side effect of making it more accessible for search engines (SEO). Which is just good sense.

The first thing you can do to improve the accessibility of your content is making accessible links.

An “accessible link” is simply a link that imparts as much information to as many users as possible. It enables the reader to preview the link, making an informed decision about whether to follow it or not, and helps to differentiate between links that may share link text but refer to different targets.

A quick reminder what a link looks like:
<a href=”URL” title=”DESCRIPTION”>link text</a>

The “accessible” bit is the title=”” part, and is called the title attribute.

This title attribute enables the reader to preview the link. This in turn allows users to more accurately guess where the link will take them, and make a more informed decision about whether or not they should follow it. Roll your mouse over this example link and you will see what I mean. The text that appears by your mouse cursor is the preview.
Example link

To code it, I typed <a href="http://www.google.com" title="this is a link to Google">Example link</a>

The title attribute can be any text you want, though to make it as accessible as possible, follow these simple rules:

  1. It should say something about the destination of the link.
  2. It needs to be between 3 and 80 characters long. A single sentence is normally sufficient.

If you are using the handy code buttons in the WordPress editor, the title attribute is controlled by the Title box in the pop-up. Another note on the link editor in WordPress – be very cautious about ticking the “open in a new window” box… It is bad web etiquette. Like in Jurassic Park, just because you can clone a T-Rex, it doesn’t mean you should. To be serious, you are taking control of the browsing experience away from the user and that is frowned upon in polite circles.

Next time, it will be accessible images… Exciting!

1 Comment

Filed under Advice

The building blocks of HTML

So after reading part one we have decided to give this HTML thing a go. What next?

First, we need to learn a little bit of new terminology, and I am going back to complete basics here.

What is HTML? It stands for Hyper Text Markup Language, and is a language for describing web pages. It is the code that controls everything.

  • HTML is a markup language, because you “mark up” the content
  • A markup language is a set of markup tags
  • The tags describe document content
  • HTML documents (web pages) contain HTML tags and plain text

The most important thing to grasp here is the idea of a TAG.

  • HTML tags are keywords (tag names) surrounded by angle brackets like <strong>
  • HTML tags normally come in pairs like <strong> and </strong>
  • The first tag in a pair is the start tag, the second tag is the end tag
  • The end tag is written like the start tag, with a forward slash before the tag name
  • Start and end tags are also called opening tags and closing tags

This : <strong>bold text</strong> displays like this: bold text.

There are a gazillion different tags you can use, but the most important ones for a blogger are:

<strong> </strong> – makes things BOLD
<em> </em> – makes things ITALIC
<blockquote> </blockquote> – styles things into a quote
<ul> </ul> (used with <li>) – make a bullet pointed list
<ol> </ol> (used with <li>) – makes a numbered list
<li> </li> – is the LIST ITEM (used with <ul> or <ol>)
<a href=””> </a> – makes something a link
<img src=”” /> – adds an image
<p> – creates a paragraph (if you are using WordPress you won’t need to use this, as even when you using the text editor it automatically puts in new paragraphs for you).

(I’ll talk about why in Part Three, but don’t be tempted to use B for bold or I for italic. It’s very naughty).

Tags always come in pairs. The exceptions you need to know are the <img> tag and the <a href=””> tag, because what would life be like if it was ALL straight forward? I’ll illustrate how they are different in a little bit. (Technically it is because they have attributes, but that’s getting a bit too complex for me).

So you have some text you want to make look bold. What do you do?

  1. Make sure your editor is set to “TEXT” view. Mine looks a little like this, but yours will vary depending on browser, computer, the blogging software…
  2. Type your content. La la la la la…
  3. Decide what you want to make bold (I think the third “la” will do nicely)
  4. Put <strong> in front of the word you want bold
  5. Put </strong> after the word you want bold
    (It should look something like this: la la <strong>la</strong> la la…)
  6. Press preview or publish. Whatever floats your boat and fits in with your workflow
  7. Um, there is no step seven. Told you it was easy.

You do exactly the same for any other tag you want to use.

Making a link:
As I mentioned earlier, links are a little bit more complicated, but not much. They look like this:
<a href=”URL” title=”DESCRIPTION”>link text</a>
And they break down into several sections.

  1. the tag itself <a></a>
  2. the link address, or URL, controlled by the href=”” part
  3. a word description of the link, controlled by the title=”” part
  4. how you want the link to display in your content (link text)

If I wanted to link to Google, I would type:
<a href="http://www.google.com" title="google.com">this is a link to Google</a>
And it would display like: this is a link to Google

Inserting an image:
Image tags look like this
<img src=”URL” alt=”DESCRIPTION” />
Like a link, they also come in several parts, but this time it is just one tag, not a pair.

  1. the tag itself <img />
  2. the address of where the image is saved, controlled by the src=”” part
  3. a word description of the image, controlled by the alt=”” part
  4. note the / inside the tag, to close it as there is no separate closing tag

Now with images I will not be too upset if you use the built in image uploader as the WordPress one in particular is quite handy. But always check the code it gives you so you know it isn’t aligning oddly, or linking somewhere strange.

And to get really crazy? Try making a image into a hyperlink… It’s possible because you can NEST tags. This is the code you need – does it make sense?
<a href=”URL” title=”DESCRIPTION”> <img src=”URL” alt=”DESCRIPTION” /> </a>

The last bit I want to discuss in a bit more detail in this post is the List. I have used both bullet point lists and numbered lists in this post. They are great ways to, well, make lists. Put each list item between a <li></li> and top/tail the block of <li></li> with <ul> and </ul>, and there you have it.

Want to practice or learn some more? Go to the W3Schools course and work your way through. It is quick, easy, and has handy “try it yourself” sections.

Go. Play. And when I come back with Part three we will go through HTML etiquette and accessibility and oodles of other fun stuff. Promise*

* For a given value of “fun”.


Filed under Advice

HTML for blogging and normal people

This is going to be a multi-part series, which will be updated over the next couple of days.

  1. Part one: Why bother with HTML at all?
  2. Part two: The building blocks of HTML
  3. Part three: Good HTML etiquette (the accessible link)

This series isn’t intended to be an in depth course all about HTML and markup langages and how to build websites because there are plenty of resources that can do that far better than I can – W3 Schools is one really good place.

Rather, what I do want to do is try and dispel some of the mystery and fear that surrounds HTML, because knowing a little can be really useful and once you know a little, you will hopefully feel more confident and who knows where that could lead? Understanding HTML will make learning/understanding XML so much easier, which in turn will open the wide open vistas of ePub and apps and codes and games and… Oh, the possibilities are endless. Trust me. I am a computer geek.

Above all, I want you to remember this golden rule: IT IS ACTUALLY REALLY PRETTY HARD TO BREAK COMPUTERS AND SOFTWARE THESE DAYS. So play. What is the worst that can happen?

(Caveat – if you are planning on tinkering with a live website, ALWAYS make a copy of what was there before you started tweaking. Things can happen to the best of us).

Part one: Why bother with HTML at all?

Most blogs run using platform such as WordPress (what we use here), Blogger, Drupal, or maybe your company has their own CMS. When you write new content, you are most likely using a WYSIWYG editor, which stands for “What You See Is What You Get”. Often it is referred to as the “Visual Editor”. Microsoft Word could be described as a WYSIWYG, or Visual editor: if you want to make a word bold, you highlight it and press the “B” button and it becomes bold. Simple. This is a little screen shot of what the visual editor looks like in WordPress. It does the magic of coding for you, so all you have to worry about is writing your blog post.

So, I hear you ask, if your blogging platform has a visual editor, why need to bother with HTML?

Well, have you ever copied and pasted text from one word document to another, and the formating Just. Won’t. Behave.?

That is probably due to unseen codes causing problems. The same thing can happen on websites. This is because every visual editor codes things just a little bit differently. Added to that, every type of web browser (IE, Crome, Firefox, Safari etc) displays HTML a little bit differently. Some are more forgiving than others -they make a best guess at what you meant – but sometimes things can get a little bit jumbled.

Also, sometimes you want to do a little bit more than the standard editor can cope with, controlling things a little bit more precisely. (I will go into more depth about this and accessibility in Part Three). You need to think of HTML as the grammar, spelling, and punctuation of blogging. And we’re all in publishing here, so shouldn’t we care about the grammar and spelling?

When you get a flat tire, you could call the AA – but isn’t it easier (and cheaper) just to change it yourself?

As I have run out of analogies, hopefully I have persuaded you all to at least look at the HTML version of the editor. So let’s move onto the basics in Part Two


Filed under Advice