Drupal Camp Scotland

Apparently the mood in Edinburgh the night before Drupal Camp Scotland had been tense due to Nigel Farrage’ being in town. However, the biggest issue on the day was the weather, and organiser Duncan Davidson explained that “rain is a good sign for a Drupal Camp”, as it means that people don’t mind being inside on a Saturday.

Drupal Camp Scotland is unusual for a Drupal Camp in that the community part runs for one day rather than two. (As an out-of-towner, I appreciated having a day to recover for work). As someone who’d signed up to attend before the speakers were announced, I didn’t know what to expect, and was pleasantly surprised to see no fewer than three strands. I was particularly pleased to see some UX talks and workshops in the mix.

Also, the food was AMAZING.


Keynote speaker Robert Douglass (who was happy to come to the country responsible for his surname) was exasperated but not surprised when he found that while most of the room had their own side web projects online, only three included a means of taking payment on them. And one of those three was Commerce Guys.

He’d also noticed that he didn’t contribute to the Drupal community as much as he used to, and moreso that this was a common statistic for Drupal as a whole (aside from a large spike when Git was introduced). His take on both of these was that individuals needed to find ways to make profit so that they had the time (and finances) to contribute.

This is an interesting take on the whole issue of whether people should be expected to work on open source in their spare time.

Douglass expanded on a Reddit AMA quote from Dries that potential niches for making money in Drupal were as agencies, Drupal Hosting and Drupal services (in order of both decreasing ease to enter and increasing returns). Douglass is involved in the latter running a subscription service and sees this as an option for those people who raised their hands to make money. He also sees Drupal 8 as making this easier through a core API, safer theming via Twig and the new CMI.


Myles Davidson’s talk on ecommerce UX featured a lot of the hints that Orange Bus end up helping clients with: remove irrelevant information, provide inline help, have guest checkout and provide default settings.

There were a few specifics that got nodding approvals from the audience such as do search and recommendations well or not at all. There’s no way that a Man United fan would would buy an Arsenal shirt, so that implies that their site is faking data. It’s all the more a shame since John Lewis recently saw an 28% increase in conversions by implementing a proper recommendations strategy. There are even machine learning service available to help with this such as Nosto.

Davidson also pointed out to be careful about using the word ‘continue’ in carts (does that mean continue to checkout or continue shopping?)

What I particularly liked was how it was based on their own study (available as PDF) and so had stats to match.

It was also wonderfully in the spirit of DrupalCamps that a service provider asked for feedback and got it. Robert of Drupal Commerce asked if they had any usability issues to work through, and Davidson pointed out address books and coupons as issues… that they’d provided patches for.


Translation module Lingotek just became the most downloaded translation module in the Drupal directory. They offer different levels of translation from machine translation (similar to Google’s) to community or internal level to full Mechanical-Turk style outsourcing. The service can track changes in the source (if entities are added or amended) and that the translations happen ‘in an airlock’ that can then be imported in.

DISCLAIMER: I particularly like Lingotek since I won their raffle for a Nexus 7.


In the afternoon, UXer Lisa Rex got Drupalers doing DIY usability testing. It’s been a full 6 years, a long plane ride and a lot more job experience since I attended a similar workshop by Andy Budd, so I was curious to see how another practitioner does it. Five Drupal sites that participants were working on were tested. These ranged from a cookery site to a university PhD section! (As someone who’s actually done the latter, I felt that the needs for that are probably too niche for proper testing, but still, any testing is better than none). Attendees were split into teams of three to facilitate, notetake and participate.

Even testing two people (all that was possible in the time) started showing up serious issues, so it looks as if it’s a useful workshop to do.

Something that came up as recurring newbie tester mistakes were biasing the script (don’t ask to buy a voucher, ask to get a gift) and saying what it was you wanted to test (even if your hypothesis is that the navigation is wrong, you shouldn’t prompt people to ask about it).


Finishing up the day was the Scottish Drupal Awards. The winners were:

  • Best Drupal Site: College of Life Sciences at Dundee (internal)
  • Best Public/NFP site: John Muir Way (Heehaw)
  • Contribution of the year: Joachim Noreiko for Flag module maintenance. This was his win for the second year running, and he later hoped that there would be more Drupal contributions in the next year so that he didn’t win it for a third time.

Other talks that sounded great but I missed were the deconstruction of how the amazing Lush website was made (something our UX team were recently admiring), and the unimitable Jeffrey “Jam” McGuire on the potential mission of Drupal (I think). I’m hoping that others blog the tracks that they saw on the day. I also heard great things about the business day that ran the day before

Oh, and, finally, in pure Scottish style, Freudian slip of the day.

Multilingual, Multidisciplinary: Drupal Northeast, GDS

You know it’s a good night for the tech industry when you have to skip out of one event right as it ends to go to another! Tonight was both the monthly Drupal Northeast Meetup, and a more informal meetup of the Google Digital Services folk (who’ve been in town interviewing for the new Newcastle Digital Centre that’s going to be based out of Longbenton of all places).

Drupal North East: Multilingual Sites

This month, Adam Hill did a live demo of setting up a multilingual site.

His overall comments on structuring a multilingual site would make a content strategist proud:

“Don’t build a multi-lingual site in English and add extra languages, start building the infrastructure for the two [or more] languages from the start”.

Part of the reason this is important is because of URL paths (if you set up the site well, they can exist clearly separate of each other) and partly because it means you can plan out how to input the translations without having to battle the admin in the different languages!

Into the more nitty-gritty Drupal stuff.

First of all: decide the source language for your site *at the start*. You can’t change it half-way through without causing a load of trouble (something which Hill’s team learnt the hard way when doing projects).

According to Hill, there are two elements of Drupal translation:

  1. content translation
  2. string translation (backend, strings, also blocks etc)

While the former is the crux of your important information, the latter is also key for making the experience of using a site truly multi-lingual. It’s also a bit trickier at times since it delves into Drupal core: if you’re lucky, your other languages will have language translations ready to  upload from drupal.org, if not … you’ll be working with someone who knows the language to figure out the appropriate translated UI words.

Hill showed that you do need a number of modules to make internationalisation play nice:

  • In core you want Content Translate and Localisation.
  • Internationalization (i8n) requires Variable to work, but as Hill showed, this is useful in its own right as it allows you to set up whether various elements such at the  language slogans and front pages have different language language options (e.g. /fr, /ar ) .Other useful ones include 404s.
  • Internationalization Views (only in dev, views generally got a lot better for v3 but this ties up loose ends) is necessary if you’re working with views, though Hill did warn that it doesn’t always quite do what you’d expect, so use with care.
  • Beyond this, menu translation, field translation, translation redirect, path translation, translation redirect, translation sets, and taxonomy translation are all self-explanatory and useful. Block translate (and context module) is also particularly helpful for controlling blocks.

In terms of setting up and implementing a multilingual site, Hill had the following tips:

  • detect language by path and folders (subdomains can be quirky). Auto-sniffing by browser is to be avoided, and while there are add-ons like IP sniffing, they have high overhead.
  • Good practices when theming and creating modules should set you up well for multi-lingual. There are some quirks to do with themes for rtl languages (namely that you’ll have to redo all your floats and padding) but since the text itself automatically switches, it’s not as big an issue as you’d think it would be.  Similarly,  anything in modules/system should be wrapped in a ‘t’ as it opens it up to be translated for translation if need be.
  • Hill has found the best way to manage menus is to just create separate ones that show up per language. This also applies for blocks.
  • If you’re dealing with a multi-author site or have images that share across languages (make sure these don’t have text embedded in them!) the synchronise translation feature can be helpful in mapping over content that should stay the same such as publish date, author name and images.

Only at the very end did he sneakily point out the very nice trilingual (including Arabic!) site annalindhfoundation.org that his company recently released.

Anna Linh: English

Anna Linh: English site

Anna Linh: French site

…and the French version (not the more verbose text)

Anna Linh: Arabic version

And the Arabic version as well as being rtl is visually sparse due to the compact language.

Some of the things his team learnt from the site was the issues of character density: as it turns out, French is more verbose than English (causing issues with labels), while Arabic as well as being right-to-left is also a far more compact language, thus making the designs look extremely sparse in comparison.

Also, random fact of the day: Hill found out that if you want to use Arabic characters in Photoshop, you have to but the Middle Eastern edition!

GDS Meetup

After that it was straight over to Brewdog to see who of the digital set were mingling with digital government peeps. From the brief chat I got to have with some of the GDC team (who’d all bravely come up from London and had apparently been surveying the Toon from a nearby hotel when not conducting interviews for the new centre) it sounds as if there’s going to be some interesting things going on in terms of cross-disciplinary teams. In unrelated matters, I got my hands on a complimentary copy of Design Transitions thanks to Emma Jefferies, which also had a surreal moment when one of the GDS people realised they were in one of the photos in the book!

Moving from Drupal to WordPress

This website began as a blog. And probably a badly made one as well. Hey, it was 2008, and I was trying to get my head around Drupal 6! Since then, I’ve moved half-way across the world, become a better Drupal and WordPress developer, and generally got into the habit of blogging a lot more.

Which is why it was time to move away from blogging on Drupal. After some consideration, I decided to migrate from Drupal to WordPress.

Why the Move?

Drupal is great for many things. Blogging isn’t one of them. I got sick of the extra time it took to upload images (WSYWIG and IMCE, sigh) and the horrible options for formatting in general. Ever since I’d been using WordPress as part of Johnny Holland, I’d been jealous. The final straw was setting up another domain on WP and live-blogging an event on it as the thought of doing it in Drupal terrified me.

Why WordPress?

There are a lot of options out there these days for writing. A lot of devs like file based systems such as Jekyll and Octopress. However, for me, the importance was ease of writing and adding media. WordPress is obviously streets ahead in this respect. While I’m really getting into Markdown, I can do without it for now as a payoff for easy media integration.

Migrating from Drupal to WordPress

A few points on the setup. I’m on Drupal 7 and migrating to WordPress 3.6.

Content

Not surprisingly, there’s a lot of ways to move content from WordPress to Drupal, but not much the other way around. After getting freaked out reading a number of posts which involved editing databases, I realised the easiest option was just to suck in the content on RSS.

I created a RSS file using the Feed view on Drupal. I then used the Multi-importer to link this to a post.

Note: in hindsight, I’d try to download the file, run bulk changes on image locations etc, and then upload it using the importer.

Images 

Images involved a bit of cleaning up on the Drupal server, as imagecache created multiple versions. To play it safe, I copied all the original size files into one folder which I then moved into WordPress. I then used the Add from Server plugin to make them all be picked up in the Media Library.

But there’s a problem! Of course, the old images have the wrong links. I went into PHPMyAdmin and search replaced all old links.

SEO

As this was a slow transition, I moved the blog site from a folder to a subdomain. Once the site was working I used .htaccess redirects to match all old urls with the new ones (the mapping is pretty close anyhow).

Comments

I’d got annoyed with spam a while back on the Drupal blog so had already moved my comments to Disqus. Luckily, there are fairly easy ways to migrate the content over. Once I installed the Disqus plugin, it was a matter of choosing the best means to migrate. As my top level mapping system had changed slightly (from http://vickyteinaki.com/blog to http://blog.vickyteinaki.com), I could use auto-mapping, but as I’d attempted to map all old URLs to new ones, I could use the option of letting Disqus sniff out the 301 redirects.

Gotchas

URL mapping

I assumed that my simple naming system would mean that the URLs would easily map. I didn’t account for one thing. Drupal’s auto-naming URL system strips out a number of small words (‘the’, ‘of’), which WordPress leaves in. This unfortunately meant that I had to go through all of the posts and check for changes. I suspect that for a large amount of posts you would just have to do bulk changes or accept a drop in SEO.

Cleaning up the WSYWIG cruft

The only real disadvantage of pulling from RSS is that you get all the formatting that comes with it. For me that was the original Disqus scripts, and numerous divs from the original feed (though this probably could have been avoided if I checked my Drupal templates).

Linking it all Back

My original all-in-Drupal site included the latest blog posts on the home page as a View. How to do that now? Again, RSS. The Drupal 7 core Aggregator module includes a block for showing feeds (though I had to add a template extra, and suspect I’ll need to make a new view so as not to end up with content duplication/SEO issues).