Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jul 14 2021
Jul 14

Option 1: Rebuild

Rebuilding in Drupal 9 is the perfect option for companies who wish to continue to get the absolute most from their online presence. It does require effort - both on the part of developers and the company itself - to ensure that the resulting system matches the business objectives in order to maximise effectiveness and ROI.

Rebuilds work best when they are backed up with proper discovery and design phases, and do not rely on historical design patterns from past iterations. As mentioned above, rebuilding in Drupal 9 is the last major rebuild required, as Drupal’s new semantic versioning makes all future upgrades far less onerous.

Option 2: Minimise

The minimise option is for those who may wish to have all the engine-room clout of Drupal 9 behind their site, but for whom it is not the right time for a full rebuild.

In this case, an option might be to minimise the feature set and build a ‘minimum viable product’ - i.e. a core website with a limited feature set, which can be expanded on in the future as business needs arise. You could liken it to 'bridging' between an old system and a new system.

Option 3: Decouple

A decoupled approach is not a conventional solution, but in certain cases could make sense. Decoupling means that the “front end”, as viewed by the public, is separate and distinct from the “back-end”, which stores the data and which would be used by website editors.

In this scenario, you could feasibly firewall off an old Drupal 7 system from the internet, but allow it to feed data to the front end for consumption by visitors. In this way, you could continue to use an established system well past its end-of-life, allowing editors to continue using an interface they know, and data structures with which they are familiar.  The front end is typically a ‘static’ site, which usually means that it is fast, secure, and requires minimal maintenance.

Option 4: Reassess

The ‘reassess’ strategy is where a company reconsiders what it wants out of its digital presence. Possibly business objectives have changed, or KPIs dictate another direction, or possibly even digital is the obvious only game in town. 

This strategy is all about making deliberate, informed decisions about how to invest in your company’s digital identity and your customers' digital experiences. Outcomes could range from a minimalist approach through full rebuild or even as far as a digital experience platform.

Option 5: Redistribute

In a redistribute strategy, a company might take a legacy monolith site which does many things, and break it apart: splitting functions and features across specialist services across the web.

For example, you could use a shopping platform for e-commerce, a GIS platform for mapping, a storytelling platform for rich engagement pieces, etc. In this scenario, a minimalist core website might tie together several disparate specialist services.

Jul 01 2021
Jul 01

We're Platinum Sponsors!

With our Gold Sponsorship and contributions at last year's event, we are excited to announce that we've taken the plunge and will be Platinum Sponsors this year!

We're busy getting our papers submitted and hope to have a number of very insightful sessions throughout the conference.

As usual, we will be preparing and writing questions for "Trivia night". The Trivia event has been one of the highlights of DrupalCon for many years, ever since the first one at DrupalCon Chicago 2011!

Watch this space for further announcements about Annertech's speaking engagements and other contributions for what is going to be an event not to be missed for all things Drupal.

Jun 11 2021
Jun 11

Drupal 8 Made Everything Better

From the beginning of Drupal 8, everything in the lifecycle just got better - including moving to Drupal 9 and beyond.

Design and research have not really changed, but once you begin to build, you start to see the changes. Drupal 8 and 9 are far more feature-complete, requiring far fewer contributed modules. With an elegant configuration management system built-in, it is straightforward to keep all settings in version control.

Beginning with Drupal 8, there is now a planned and continuous improvement release cycle for new versions of Drupal. This means that new features don’t have to wait for a full new major release: instead, they are incrementally included in new software releases every 6 months.

From a typical release page, they say “This minor release provides new improvements and functionality without breaking backward compatibility for public APIs”. Some examples of new functionality which have come online through this process include, media handling, content workflow, layout builder, to name but three.

As before, minor upgrades are straightforward, but the most significant change is that major upgrades no longer require a complete rebuild of your site. As only deprecated APIs are removed in each major upgrade, upgrades can now be completed in a fraction of the time. In fact, most are completed in a matter of days, and not months as before, and usually with only minimal effort on the part of the site owner.

A site redesign can also be performed at a time dictated by business needs, and does not need to be coordinated with a 3rd party release cycle. 

Jun 02 2021
Jun 02

1. Scalable across multiple departments

With numerous departments, research groups, student organisations and other entities comprising a university, it can be a struggle for higher education institutions to maintain governance and keep track of the hundreds of adjacent sites that may involve.

Fortunately, Drupal provides two options to enable higher education institutions to centrally manage and control the brand while still giving content independence to each department.

First is Drupal's multisite feature, which makes it possible to run as many sites as you wish on the one Drupal installation, each with their own database and sets of users. These individual sites can share code, components and themes providing better reusability across different websites. 

An alternative to this approach is to use the Group module. This extension allows you to create arbitrary collections, or groups, of content and users within your site. Here a group is created for each department or group, and editors then assigned to one or more groups. 

With one codebase, one database and the inability for configuration settings to vary across department "sites", the Group module provides even tighter governance controls to higher education institutions.

Both of these solutions reduce the time and cost involved in launching new sites, while also improving governance, brand consistency, and maintainability, and still offering autonomy to each department or group.

Apr 26 2021
Apr 26

In Annertech's Technical SEO Service for Drupal Websites, we talked about what we do during a technical SEO implementation. But let us now look at the longer-term benefits of implementing one for your organisation.

1. Increase Reach Across all Channels

When your content is created in such a way as to allow Google, Bing and others to easily discover it, index it, and display it, it stands to reason that more people will also find it. With this increase in reach across different channels, you have the inevitable increase in potential sales and engagement.

2. Increase Search Engine Ranking

Following-on from the last point, if Google can easily understand your content, it stands a much better chance of appearing higher in search results, up to and including “Position Zero”. This means not just being at the top of general search results, but also featuring within the "People also ask" and "Featured snippets" section. Being placed here is Google gold dust.

3. Rich Snippets in Search Results

When your content appears in search results, you want more than a title with a short description; you want images, video, ratings, call to actions, etc. Anything that makes the search result showing your website more enticing than your competitors is a real bonus. Remember, a more enticing or prominent result will mean more engagement.

Nov 23 2020
Nov 23

4. Track team

This year's DrupalCon will feature well-over 100 sessions, across five tracks, and also four deep dive workshops that are not to be missed (for the first time, these workshops are included in the price of your ticket).

For a number of years, Annertech has provided volunteers to chair tracks. This involves many meetings about the conference to decide what the tracks will be, answering questions from those who wish to speak before sessions are submitted, reviewing and rating sessions after they are submitted (hundreds get submitted, so this is no small task), awarding speaking slots, and ensuring speakers are taken care of during the conference.

Our Director of Projects, Mike King, has been a track chair for many years, including chairing the Agency & Business track this year. In previous years, Mark Conroy, our Director of Development, has chaired the Frontend and Site Building tracks, while Stella has chaired numerous tracks from Agency & Business to Higher Education.

Aug 19 2020
Aug 19

Drupal 8 was released in late 2015, heralding a significant departure from its predecessor, Drupal 7 and required a complete re-build. 

However, the benefits of moving were evident early, and companies who decided make the jump were glad they did so.

The benefits included:

  • Ease of use - in-place editing, using CKEditor 
  • New theme engine, using Twig
  • New Symfony Framework
  • Enhanced multilingual capabilities
  • Extensibility - enhanced capability to integrate with third-party systems
  • Better performance - using BigPipe technology that loads pages quicker
  • Media library - browse and reuse media across your site
  • New features - new features are released every 6 months

But the big news was that there would be no more major re-builds – you didn’t have to re-build the site for future upgrades, new features will be carried out in smaller updates.

Though Drupal 9 does not offer any new features in its initial release, it does offer a leaner, more secure system with APIs that are easier to work with - these changes are most noticeable to developers.

Future releases of Drupal 9 will continue to feature additions and improvements along the six-month release timeline that has been established with Drupal 8.

Aug 11 2020
Aug 11

In conclusion

The challenges of creating a great digital experience today are ever growing, and if you are looking for a more flexible, more customisable alternative to SharePoint, then a move to Drupal should certainly be considered.

Drupal is widely regarded as the world's leading open-source enterprise platform for building content-rich digital experiences. Its highly flexible, scalable and extensible nature enables organisations to build better sites and experiences faster.

Moving away from SharePoint may seem like an insurmountable task, but as this article shows, the challenges can be overcome and you need not remain stuck on SharePoint forever.

If you are considering a move to Drupal, then Annertech is an award-winning Drupal specialist digital agency that can guide you through the process, helping you define a clear strategy and enabling you to make a smooth transition. 

Jul 10 2020
Jul 10

Thursday, 16th July, 18:15 - 19:00 (UTC)
Speaker: Christopher Torgalson
Track: DevOps & Infrastructure

In his session, Christopher will outline some of the most prevalent issues that make automated tasks less safe, secure, reliable, and performant. On the back of these learnings, he will then discuss how we can design better quality automation for ourselves and our clients.

As usual, we've been busy preparing and writing questions for Trivia "night". The Trivia event has been one of the highlights of DrupalCon for many years and at DrupalCon Global 2020, this is no exception - except this year, we will have teams from all around the globe! In addition, rather than it happening in the evening time, the event will be split across the three days of the conference. For more details on the times, see the conference website.

Jun 10 2020
Jun 10

What's new in Drupal 9?

With the release of Drupal 9, there are no major changes, no system overhauls, not even any new features! The only differences between Drupal 8.9.0 and Drupal 9 is that those deprecated APIs have now been removed, and a number of third-party dependencies (Symfony, Twig, etc) have been updated to newer versions which will be supported for longer.

This means that as long as you are already on Drupal 8, and have been keeping your site up-to-date, upgrading your site from Drupal 8.9.0 to Drupal 9 should be a relatively pain free process.

Are Drupal 7 and 8 still supported?

Yes, Drupal 7 and 8 will both be supported until November 2021, at which point both versions will reach their end-of-life (EOL). It is highly recommended that you upgrade to Drupal 9 before then. After this date, these versions will no longer be supported by the Drupal Security Team which means no future security patches or bug fixes will be released for these versions.

This is the first time that two major versions of Drupal will become unsupported at the same time. The timing of Drupal 8's EOL has been planned to coincide with the EOL of one of its third-party dependencies, Symfony 3. As the upgrade path from Drupal 8 to Drupal 9 is so simple, it is unlikely that any extended support will be available for Drupal 8 beyond this date.

Drupal 7 is a different story though. There will most likely be a small group of approved third-party agencies who will provide long-term security support for Drupal 7, for a fee of course, for those organisations which are not ready to undertake an upgrade just yet.

However, there is still a year and a half before they reach their end-of-life, so there is plenty of time to upgrade your site - you just need to start planning for it now.

Upgrading from Drupal 8

If you are using Drupal 8 already, then the process of upgrading to Drupal 9 is relatively seamless and pain-free.

  • The first step you should undertake is to ensure that you are running the latest version of Drupal 8 and any contributed modules you may be using.
  • Use the Upgrade Status module to check whether your custom code and contributed modules are Drupal 9 ready.
  • If any contributed modules are not Drupal 9 ready, then check their issue queue and work with their maintainers to remove deprecated code.
  • Remove deprecated APIs used in your own custom code too. The Rector module can assist in resolving these automatically.
  • Lastly, make sure your hosting environment is compatible with the updated requirements of Drupal 9.

At this point you should be ready to upgrade to Drupal 9! Of course, as with any upgrade, we recommend taking a backup and testing it in a non-production environment first.

Upgrading from Drupal 7

There is no upgrade path from Drupal 7 to Drupal 8, or indeed Drupal 9. Essentially your site will need to be rebuilt from scratch and any content you want to retain migrated into the new structures. While this is a large undertaking and may seem a bit daunting, it's also a huge opportunity.

Drupal 7 was first released in January 2011. By the time it reaches its end-of-life in November next year, it will be over 10 years old! That's 10 years of no new features, other than what can be provided by contributed extensions. Ten years is a long time in the life span of any software, but particularly so in the online digital space, where technology advances rapidly.

Upgrading to Drupal 9 is the perfect time for you to re-evaluate your online digital strategy, to re-assess your messaging and positioning. It's a time to enhance and improve your customers' experience online. It's a time to take advantage of the new innovations and features released on the platform every six months.

At Annertech, we deliver ambitious digital experiences for our clients, and with Drupal 9 we know we have the ideal digital experience platform to deliver on that aim.

Isn't it time you started planning your upgrade now?

Jun 03 2020
Jun 03

Every new version of Drupal has had the headache of the upgrade path - from 5 to 6, from 6 to 7, from 7 to 8. What this often meant was re-building the site in the new version and then doing a migration of the content. This was expensive for clients. With Drupal 9 (and the versions that will follow), this is now a thing of the past.

Drupal 9 is the exact same codebase as the last version of Drupal 8, with just two changes:

  • Updates of dependencies to versions that stay supported
  • Removal of our custom Drupal code that has been marked as deprecated

This means, if your site was running on Drupal 8, and your developers kept it updated to the latest version of Drupal 8, you just need to make sure that any contributed modules and custom code are not using deprecated functions. If that's the case, hey presto - you're website is Drupal 9 ready. I don't think we can underscore how good a feature this is strongly enough.

New Features

But surely there are some new features? No, not in this release - and that's good for now. For Drupal 9, we have the same feature set from Drupal 8. Drupal 8 introduced the idea of new features in each minor version (8.1, 8.2, etc) rather than having to wait for the next major version (Drupal 9). This means Drupal, during the 8.x lifecycle, got lots of new features - media in core, umami magazine profile (for which I am a core maintainer), layout builder, JSONAPI, and more. For Drupal 9.0, there are no new features, though that will change from 9.1. Once we get over this first release, expect new features again every 6 months.

Apr 03 2020
Apr 03

Previously I wrote about the hidden power that resides in the hands of a designer. Here are 10 questions you can apply to a supplied design, and the answers to them, or even the process of getting those answers, can bring a good design through to being a great design for your project. Remember, a design is just a picture until it is implemented, and it is important that the technical implementation is considered at the design stage.

1) Image Sizes

How many image sizes are there across the site? How many different aspect ratios? Is there any commonality between images? Where can we reuse an image? In Drupal terms, we're asking: Can I use image styles? How many do I need? In which area of the site can I use each image style?

If there seems to be no obvious pattern, it can be worth articulating the benefits of using standardised image styles to the designer, such as performance and improved editor experience.

Remember that with a responsive design, images will usually stretch to fill a space, so image styles will generally set an image to its maximum required width. The single most important thing to consider is aspect ratio. If all the images have the same aspect ratio, then the implementation of a design becomes much, much more straightforward.

2) Content Order

In a responsive site, as screen size diminishes, chunks of content flow around each other and jump below other content to accommodate the smaller screen width. It is important to realise that designs for smaller screens are sometimes supplied without due regard to this flow of content. If you see content order on a mobile design that doesn't match up with that in the desktop design, ask about it. Either it is a mistake that is easy to rectify at the outset of the project, or it will turn into a monster that will eat your budget.

3) Horizontal Alignment

People love horizontal lines. They particularly love columns of content, with line breaks, each of which line up with its neighbour in the next column. Unfortunately, the web, and responsive design in particular does not make such a design easy to implement.

It is bad practice to set absolute heights to elements in responsive design, to allow elements to expand as necessary, but without control of heights, any content change or width change will break the layout. As widths decrease, the height of content in a restricted space increases, which means that either the content will overflow its bounds, the content will be clipped, or the container expands, breaking the nicely arranged horizontal alignment.

There's no easy solution to this, so it is important to bring it to the attention of all concerned early on, lest it become an issue late in the project when deadlines are tight.

Often this issue only comes to light at launch time, when a client is putting real content, and replacing the nice, consistent three lines of dummy text in the design.

Ask how much content should be in the space. Ask whether the lines need to line up. Ask whether you want to rely on brittle Javascript to make heights equal. Ask early.

4) Long Titles

In a typical design, in my experience, titles and teaser text will be short, bordering on terse, lending themselves to smart, ordered layouts, and small containers in which to fit these elements.

When a site is live in the wild, titles can be really, really long. Editors are given content, control over which they may not have. The design has to accommodate this situation. Try swapping out
'Lorem Ipsum Dolor Sit Amet.'
'Many editors struggle to fit their content into the cramped confines of a small title block.'

Then see if the design still works. Ask about maximum title length and the ebb and flow of text on the web.

What happens with a long title on a small screen?

5) Large, Full Screen Background Images

Do you really need it? How big is it in kilobytes? Is it worth the extra page weight? Can the weight of it be reduced by blanking out where the content will live? What happens on small screens? Do they need to download it?

Think of performance, think of the value of that background image, and think of mobile users.

6) Fonts

What fonts are in use? Are they special? Is there a cost associated with them? Do they have all the necessary characters in the font? (e.g. I recently had to use a font that had no ampersand character.) Does the client know about any cost? Are they happy with that? Where are webfonts in use? Are they just for headings? Or are they for body text? Do they work on cheap, low-resolution screens? (If they don't, it's probably a poor choice.) Is the 'Flash Of Unstyled Text' before the webfont loads acceptable? How much does the font add to the page weight? Can you use a subset of the font? Do you need bold, italic and other variations?

7) View Modes

How many different ways is the same content (e.g. a node or a bean) viewed on the site? Where on the site are these places? Each different representation directly corresponds to a View mode. If there are many variations, can these be rationalised? View modes are immensely useful, but there comes a point where YAVM (Yet Another View Mode) becomes painful. Less is more.

Another consideration here is seeing if view modes can be shared across content types. For example, is the listing page for news posts the same as the listing page for events? If so, we can use the same view mode for both? This will cut down on the time needed to style these view modes with CSS.

8) Configuration

Does the client need to configure anything? What does the site editor want to be able to change? Should footer blocks be editable? Or any of the site chrome? Should only the main content area be editable? Should the site editor be able to modify listings? Panel Pages? Forms?

The answers to these questions are relevant because they directly affect how you approach a build.

(Aside: read our article The Drupal Content Editor deserves and easy Life.)

9) Browsers

What browsers need to be supported? Can the design even be properly implemented in older browsers? What does 'graceful degredation', or 'progressive enhancement' look like in practice with this design? Which design elements, e.g. funky CSS3 effects or killer Javascript libraries, won't work in poorer browsers? Is there a fallback? Should there be? Ask about analytics. What are the actual site visitors using?

The older the supported browser, the more it will eat into your budget, and the older you go, the more it will eat.

10) Colours

How many shades (e.g., of grey) are there in the design? Can you tell the difference between them? For lighter shades, can you even see them on a poor screen? You can bet that the design was put together on a high quality, high resolution, bright screen. Does it work on a low budget, 10 year old 15" LCD screen? If colours cannot readily be differentiated on such a device, then they may be surplus to requirements.

Further Reading

Josh Riggs' excellent presentation from Drupalcon LA on creating great design without a huge budget.

Would you like to create something beautiful?

Ask us about it.

Oct 15 2019
Oct 15

What a UX designer thinks will be quite different from what a mechanical engineer thinks, which will be worlds away from what an artist thinks.

For example,

  • I am a trained civil engineer. As an engineer, design is in providing the minimal technical solution that fits the brief.
  • I often work in the role of a (web) site architect, where design is in accurately modelling business data to provide efficient and scaleable solutions.
  • I was never great at graphic design as my photoshop-fu is weak, but I always understood that as a graphic desiger, design is in creating beautiful interfaces for people to interact with.

As a developer, which takes up most of my daily work, I take website designs created by others and implement these into real, usable, functional software. I'm going to talk about things I have seen on real projects, with real clients and perfectly competent teams, where the design actually hindered the build process.

Building The Foundations, Out of TNT

Design can easily make or break a project, and graphic design is easily the most impactful of all design processes. From this point on, any references to 'design' will refer to web design, the graphical design of a web site, such as is often delivered as a Photoshop file (.psd) for implementation by developers.

I have seen great projects with great project teams really struggle because a design, whilst beautiful, was very difficult to implement. Conversely, a design that facilitates ease of implementation can make the project a joy to work on, and will result in a happy client and success all round. Site owners love something that they can 'sign off' on, and more often than not, the first thing that is signed off is the design, which can become a Bible against which the entire project is measured. It is little wonder that design can have such wide-ranging implications.

Deep Impact

There are many ways in which design can impact upon a project.

It's a safe assumption that a website will be built upon a content management system (CMS) - in Annertech's case, we use Drupal. The CMS will have a way of doing things, and the design can work with it, or the design can hinder it.

Nowadays, every site should be a responsive site. But does your design naturally lend itself to being responsive? This does not mean that as a designer you should create separate designs for multiple screen-sizes, but rather that a given design should naturally adjust and flow for different devices. In fact, having a separate design for mobile and tablet-sized screens to desktop can actually hinder development because of inconsistencies of design elements across Photoshop files. Without a solid understanding of how devices interact with and render a page, how page elements float and stack and expand and contract, you run the risk of a design that requires undue effort to force onto a small screen, resulting in a sub-optimal end product. When designing adaptive layouts, content order really matters too. The natural order and flow of DOM elements (if you are not a developer, read: "things on the page") should not have to be adjusted based upon screen width. To do so adds unnecessary complexity and will again probably impact upon performance - how quick your site is rendered on a screen for users.

An Artful Work of Fantasy

Sometimes a design will show visual effects that CSS simply will not produce. Whilst often these effects can be created with enough Javascript and imagery, often the trade-offs (maintainability, performance, page weight) are not worth the gain. Mobile performance, especially, can fall victim here.

A Font is Worth 1000 Pictures

Any designer worth their salt will tell you that font choice is hugely important. This is undeniably true. But the following things are often forgotten when choosing fonts:

  • A font can add considerably to page weight, depending on how many weights/styles you include.
  • On large and complex pages the Flash of Unstyled Text (the screen showing default fonts before the correct ones get to load) when using javascript-based font-replacement techniques can by very jarring. It can also be rather slow to go away on older browsers/machines.
  • Fonts can be expensive, and clients do not always want to pay for them. The smart money says: find out what the font budget is before you do your design. For example, a Photoshop design showing Proxima Nova (€615.99) will never look like a site built using Arial. This will cause untold friction between developer, designer and client over the build process.
  • Not all fonts are created equal. Some fonts might look lovely on a crisp MacBook Pro with retina display, but make sure you look at them on Windows, with a shoddy old 17" monitor. Often that is quite a different experience.

50 Shades of Grey

Great design is all about subtlety and attention to detail. However, this should not deliver a licence for the inclusion of unnecessary detail.

For example, a consistent and concise colour palette is a thing of beauty. However, more than a dozen shades of grey, many indistinguishable from one-another to the lay user, is merely an expensive waste. Again, try out the design on a low-budget monitor: can you tell the difference between #ffffff and #f4f4f4? If not, you probably don't need that level of subtlety and should simplify your design. Yeah, that's right: shots fired in the Needless-Shades-of-Grey wars.

To put it another way, consistency of design elements is a really powerful tool in a web designer's arsenal. Consistently presented elements, re-used in a logical manner, can endlessly simplify CSS, speed up site builds and improve performance. Clearly this is a desirable outcome!

An Appeal for Sanity

Speaking as a developer, this is my plea to designers everywhere to think about how your design can be implemented. Every addition to the design will have an impact on the build and probably on the end user. Is it necessary? Will it enhance or hinder? The ideal is design in the browser, so that you can mock up interactions, see how DOM elements (again, "things on the page") react to changes in screen width and look at what CSS can achieve and what it can't. This is not about asking the designer to do development, but rather to ensure that the agreed-upon design can be practically implemented.

Shucks, as a designer, you might even ask the developer "hey, any problems implementing this before I ask for sign-off from the client?".

Website owners: It's Up to You

Prospective site owners: people who would like to get a Drupal site built. This appeal I direct to you: "Do not accept the artful work of fancy."

There are two possible scenarios stemming from an impractical design.

  1. If you get the design before contracting a development team, the price will be higher than otherwise, as the design makes it more difficult.
  2. If the design is late and the developers have already begun, the project will be late as the effort required will be far greater than originally estimated.

Rather, ask for a design that works with your choice of CMS. One that facilitates responsiveness. A design that is not unnecessarily complicated. These are often the most beautifully simple, accessible designs. Everybody wins.

Love Your Developers

This final plea is one directly related to Photoshop. It is an amazing tool, and one that facilitates wonderful-looking sites. However, I open PSDs with dread. But it does not have to be that way. Herewith, a couple of tips to make the dev in your life happy:

  1. Name your layers. Names like 'Layer 35 Copy' make developers sad. We who are not conversant with the mysteries of Photoshop really find semantically named layers useful! (such as "Sidebar block, heading")
  2. Apply your layer effects. Unless one actually possesses a copy of Photoshop, one cannot see layer effects. Gimp and Preview won't parse them. Be nice to your devs and apply the effects to the layers that require them so that when we slice up a layer, we get the colour you intend and not a pale imitation.


Modern websites are really complex, and it takes a team of dedicated, skilled people to create them. The designer is often the first onto the green field site, and is arguably the person with the most far-reaching power. I suspect that many designers simply do not realise the depth and breadth of their power.

I think that in an absolute ideal, a designer would work alongside the developers, rather than rather than handing over "signed off designs", to create a site that is a harmonious thing of beauty.

Let's work together.

* No sites were harmed in the writing of this blog post
** Whilst all examples come from real life, names have been changed to protect the guilty parties
*** We'd love some cake, if you're sharing

If you want to discuss Annertech helping you build an award-winning website, please feel free to contact us by phone on 01 524 0312, by email at [email protected], or using our contact form.

Sep 10 2018
Sep 10

As ever, we have brought our bags of knowledge with us to share out our goodies. On Tuesday, Mark Conroy will co-present on the new installation profile and theme for Drupal core - Umami. This is part of the "Out of the Box" initiative of which Mark is co-maintainer. Mark will be accompanied by two other leads from that initiative - Eliot Ward and Keith Jay. Later on Tuesday, the three will co-host a BoF to set the parameters for what they want to achieve during the weeks' code sprints.

Also on Tuesday, Stella Power will co-present a session on Drupal governance. Maybe you already heard about the Governance Task Force. This is a chartered group that was formed to make a proposal on community governance in Drupal. The session will share what the task force is doing, how to get involved, and the current progress of the Task Force.

Not to be outdone, David Thorne will - again on Tuesday (we've a busy Tuesday!) - give a presentation on the Islandora CLAW distribution for Drupal. This talk will introduce CLAW's key concepts to educational establishments, many of whom may already use Drupal for websites, as well as Fedora Commons for their digital asset collections.

Wednesday is the day we'll all relax after our presentations on Tuesday, and look forward towards Thursday where we'll host the usual (pretty crazy) Drupal Trivia Night Quiz, along with an army of volunteer runners, judges, and the ever-dapper host - Anthony Lindsay.

On Friday, we'll crack open the laptops and contribute as much code as we possibly can to the Drupal project, before flying home Friday night and Saturday morning.

Oh, and - we're hiring!

Mar 30 2018
Mar 30

This is not a new phenomenon, and is testament to the efficiency and professionalism of the Drupal Security Team that these vulnerabilities are found, fixed, and the releases managed appropriately.

The release meant we had to update every single client site quickly, across multiple versions spanning Drupal 6 to Drupal 8.5, so our team immediately swung into action, developing a plan for each site. 

We've got your back

On Wednesday 28 March, around 8PM, the new versions of Drupal were released. Our team were poised, fingers on keyboards around Ireland, the UK and France, and rather than panic in the face of a large, time-sensitive job, we set to work.

Over the next couple of hours our shared spreadsheet tracked all the updates, steadily turning green as site after site was updated. Chat, jokes and on-mission discussions flowed freely through our chat channel as the team worked with one mind and one goal. In truth, it was a fun and exciting evening! By midnight we surveyed the end result: 70 sites updated, development and staging environments updated, and one redesign project even deployed to the live server!

1 team, 70 sites, 6 versions, no problem

Every member of the Annertech team did us proud, and because of our efforts on Wednesday evening, not a single client site of ours remained vulnerable to the exploit. Job well done!

Have you updated yet?

If you have a site that is not yet updated, and you need help doing it, don't delay: please get in touch - we'd be glad to help.

Oct 31 2017
Oct 31

To achieve the first, we had a strict policy on "no case studies, no sales pitches". Instead we specifically asked for people to propose talks about migration, multilingual, headless Drupal, test driven development, component-based theming, etc. Naturally, the Drupal community didn't let us down and provided two days of very high-level sessions on these and more topics. (As an aside, one attendee told me he didn't get to DrupalCon, but did manage to get to four DrupalCon sessions at Drupal Camp Dublin.)

To achieve the second, we deliberately scheduled our camp for 2 months after DrupalCon. This would allow us to talk to people at DrupalCon and encourage them to come along. Added to that, we contacted people we knew from other Drupal communities outside of Ireland and asked them if they would like to come to our camp and to promote a tweet or two for us. This was a successful endeavour with about 33% of attendees at Drupal Camp Dublin coming from overseas, mostly the UK and Belgium.

So, what was talked about? We'll here's a lightning talk blogpost of each topic (yes, I managed to get to every session across two tracks, except for one session that was on the same time as one of my own).

Lessons Learned from Building a Large Multilingual, Multi-region Site in Drupal 8

This was a shortened version of Stella's talk from DrupalCon. A fascinating look at the quirks of building a website with localised content, rather than just multilingual content. For example, showing a blog post to users in Europe, but not to users in Asia; an English language report in US English for the US audience and UK English for the rest of the world. There are more pitfalls than you might think, but Stella covered them all.

Surviving your job when having ADD

Levi Govaerts gave a wonderful talk on how having ADD affects his life and work and strategies for coping. I tweeted to him later to say I'd love to see such a talk given to a larger audience, such as a DrupalCon audience. I hope this happens. Very insightful.

Lean Web Operations — Planning for the unpredictable

This was a talk from Jochen from FreistilBox. As usual, Jochen delivered a very engaging talk on "getting things done" with his typical humour and deep knowledge. In short - stop starting and start finishing.

A Headed Goal for SSE Airtricity League with Headless Drupal!

This talk wasn't so much a headless goal as it was a triple header. There was so much to get through here it took three very capable developers from Monsoon Consulting to deliver it, the talk focussed on building a Drupal backend for a headless Angular JS frontend for the Football Association of Ireland.

Clearing out the cruft - Using Migrate API to migrate a 12 year old site

Alan, from Annertech, has been maintaining the Athenry running club website for a long time, starting with Drupal 4.7. Each new major release of Drupal allows Alan to see what has changed about Drupal migration from version to version. In this talk he looked at the workflow needed and how to migrate from media in Drupal 7 to Media Entity Embed in Drupal 8 as well as migrating to paragraphs.

Estimates are dead, long live forecasting!

I apologise for turning this well-prepared talk into a discussion. But I couldn't stop asking inline questions because what Mike King was talking about had such a resonance for how developers work. Basically, we need to use data to let our clients know our 'forecast' of work completion. We cannot estimate with any accuracy.

One-click automated builds

Luis Rodriguez from Capgemini gave this talk on making your development workflow easier by automating as much as possible. I wish I knew as much as Luis about this kind of stuff.

Case study : making Commerce, Webform & Group play nicely together

Okay, we said strictly no case studies, but this one was worth it. Chandeep Khosa gave a great overview of how he has used webform and Drupal commerce along with the group module to allow quite complex pricing rules to deliver products to clients.

Live Performance Workshop: A top-to-bottom performance overhaul

Anthony Lindsay, from Annertech, shocked us all with some terribly bad code that would make a site very slow (the type of code we have seen and fixed for some of our clients). After we got over the shock, we set about fixing it, together, as a team with everyone giving whatever knowledge we had until we got the site from a 5 minute page load to a 2 second  page load.

Deploying Drupal (and anything else) with Fabric

This was the first  of Oliver Davies's talks, in which he demoed some very clever things he has been doing with Fabric to help his deployment workflow.

Back to the Future: No More Static Mockups!

Without doubt the best talk of the weekend, not just because it was by me! This was a version of the talk I gave at DrupalCon, where I go on my usual rant about why we need to stop sending clients photoshop mockups of their websites and start using PatternLab (or at least design in the browser).

Teaching Development via Drupal

I missed this talk because I was giving mine at the same time. From comments from people who were at it, I'm sorry I missed it. Apparently a great talk along the lines of "I am teaching CMS developer at a third level institute. What should I be teaching about Drupal".

There's more to code reviews than you might think

This was a great introduction from Daniel Shaw about how to get started with code reviews, why code reviews are not supposed to be scary, and how they can make your developers even better developers.

Drupal 8 Sitebuilding with Paragraphs, Display Suite & Configuration Management

Chandeep's second session. This time he gave a preview of how he uses paragraphs and display suite to allow him to deliver complex requirements without writing code, and also give the editor as good a user experience as possible.

TDD - Test Driven Drupal

This was Oliver Davies' second session. in this one, he expounded on why we should write tests, how to get started writing them, and - crucially - why using TDD can help you work faster and find bugs sooner.

A foundation in Drupal development with Docker

This was one of those sessions where I know very little about the topic but like to attend so I can at least gain some vocabulary about it. Ed Crompton didn't disappoint, and now at  least I know the difference between a Docker image and a container.

Growing an Agency Business: Tactics Vs Strategy

Bharat Sharma from Monsoon Consulting stepped in to give this talk when another speaker had to cancel. In it he dissected the process his company went through a few years back to re-shape themselves and the type of client they wanted to work with. There was a lot to take away from this talk for any company looking to scale.

A New Theme for Drupal Core?

I gave this presentation as the last one of the weekend. It was a short and simple overview of the work we are doing as the 'Out of the Box"' initiative for Drupal Core - building a demo installation profile for an imaginary food publishing magazine called Umami, which will become part of Drupal Core 8.5.x (if we meet our deadlines).

And that was it. Drupal Camp Dublin 2017 - in my opinion the best Drupal Camp we have had so far in Ireland.

Sep 25 2017
Sep 25

Estimates are dead, long live forecasting!

Tuesday, 26th September, 11:20-11:45

Speaker: Mike King
Track: Project Management

In his session, Mike will outline the good, the bad and the downright wasteful aspects of estimates and how they’re used, before contrasting it all with the positive benefits of using forecasting to communicate a range of outcomes and how this can be communicated with the wider team. There will also be a follow-up BoF to share open source tools so that everyone can take home this new set of skills.

Lessons Learned from Building a Large Multilingual, Multi-region Site in Drupal 8

Tuesday, 26th September, 14:15-15:15

Speaker: Stella Power
Track: Site Building

Thinking of adding multilingual functionality to your Drupal 8 site? Then this is the session for you. Here Stella will take you through the fundamentals of configuring your content to be multilingual and the various pitfalls and lessons learned along the way.

Core Accessibility: How are we doing, and what can we do better?

Wednesday, 27th September, 10:45-11:45

Speakers: Andrew Macpherson (and Théodore Biadala and Kristen Pol)
Track: Core Conversations

In Drupal core, we've been making great strides incorporating accessibility best practices into the UX and markup. It’s not only important to help increase Drupal product adoption in some markets (e.g. the public sector) that have strict accessibility requirements, but accessibility is important to make Drupal sites reach the most people with varying backgrounds and abilities. This can be good for business. It is certainly good for our humanity.

Back to the Future: No More Static Mockups!

Wednesday, 27th September, 15:45-16:45

Speaker: Mark Conroy
Track: Front End

This presentation will be an easy-going rant about how to make things better for frontend developers and will start by taking a look at Photoshop, SketchApp and InVision and how these tools fail to deliver. We will then move on to talking about designing in the browser and how tools such as PatternLab and Fractal can help solve these problems. Finally, we'll look at how we can (easily) integrate PatternLab with Drupal, thereby going 'Back to the Future'.

Live Performance Workshop: A top-to-bottom performance overhaul

Thursday, 28th September, 13:00 - 13:25

Speaker: Anthony Lindsay
Track: Performance and Scaling

Come participate in an interactive performance workshop. Here you'll get to view a broken site and all the awful performance blunders that were made, and more importantly how to fix them.

There's a brief overview of each of our speaking slots. Be sure not to miss them, and don't forget to come say hello to us afterwards!

Photo credit: Franz Jachim

Sep 19 2017
Sep 19

I got a request today from a former colleague:

@marky I need some quick practical selling points why our designers should stop using dedicated design programs and design in the browser instead. 2 or 3 should do!

I guess he had to add in the "2 or 3 should do" knowing I'd go off on a long rant. In either case, I gave him 5, here they are:

1) Don't Build Up Expectations for Your Client

When you use a static tool such as Photoshop, you build up expectations for your client. What usually happens is that all titles are the same length, all images have the same crop proportions, etc. But when your client adds real content, the rendered page looks like an approximation of the design.

With design in the browser, what you show to your client is what your client will get.

2) Quicker for Implementing Change Requests

If changes are needed, they can very quickly implemented by editing classes in CSS (for example, the new theme for Drupal core has a base font size of 15px. We’ve decided to up that to 16px - which means one line of code in CSS - instead of redoing all the Sketch files). The same is true if you want all image in a teaser list to position on the right hand side of the text instead of the left. Doing this in Phhotoshop is a pain.

3) QA Starts Sooner

QA testing can start waaaay sooner than using Photoshop or Sketch. As the client is signing off the designs (or each component) they are also signing off the frontend QA. Using something like PatternLab with Twig you can have almost the whole Drupal theme developed in this design phase, and then get the backend developers to output the HTML that will match it.

4) Signoff is on Real Devices

Client will see the designs in a real device and how they will render on that device - not looking at a mobile design on a desktop screen. When a client looks at a pdf of their new site, they will zoom out until the text is unreadable to see the whole page on one screen. No one will ever view the site like that though. Design in the browser forces your client to view the site as it will finally be viewed, in whatever browser/device they choose.

5) Multiple Variations is a Breeze

It’s very easy to show different variations of the same design (e.g. blog post with short title, long title, no image, etc) to see how the design stacks up against these real-world scenarios. This takes much longer in Photoshop or Sketch if you need to create individual mockups for each. Again, using PatternLab for this, you can have a base blog.json file (with the data for the blog component) and then extend that with each variation you need blog~long-title.json (with just the title variable changed), blog~long-title-no-image.json (you get the idea).

Okay so, at this stage it looks like I'm not a fan of Photoshop (I'm not) or InVision (I'm definitely not), or Sketch (I am! I love Sketch). So is there are place for these tools? Well, yes. If you designer likes to use them, and can work quicker with them (maybe he/she is not a frontend developer), then by all means they should use them. As each component is designed, they can then hand them over to the frontend team to implement them as HTML/CSS/JS, and it's these files that are sent to the client for signoff.

Won't that take longer? Initially, yes - it'll take a little longer to get the designs to the client, but the payoff is in how much sooner QA is done, how the client doesn't expect a unicorn to eventually be delivered as that is not what they signed off, and ... at some stage you are going to have to write the necessary HTML/CSS/JS, so why not early on?

After all that, what was the response from the person who said "2 or 3 should do"?

/me has started wondering how to turn @marky off now that he has started him...

I'll be speaking about this at DrupalCon Vienna on Wednesday 27th September at 15:45. My talk is titled: "Back to the Future: No More Static Mockups!" I'd love to chat with you there.

Here's a video of a similar talk from Frontend United in Athens this year:

Jul 31 2017
Jul 31

On Friday, all the accepted sessions for DrupalCon Vienna were announced, and we are delighted to report that, once again, 5 of our 8 session proposals were accepted! With Acquia and Pantheon being the only companies receiving more acceptances, we are extremely proud of our achievement. It also means that given our size, Annertech has more speakers, per staff member, than any other agency in the world.

This is the second year in a row, where we have had 5 sessions accepted for DrupalCon, and, along with FreistilBox, are the only Irish web agency to be represented. Our sessions this year span a number of different tracks, namely Project Management, Site Building, Performance and Scaling, Front End and Core Conversations, and cover topics such as building multilingual sites in Drupal 8, project forecasting, debugging performance issues, component-based design/development, and accessibility. Congratulations to all our speakers!

Here's a quick run down of each session.

Live Performance Workshop: A top-to-bottom performance overhaul

Speaker: Anthony Lindsay
Track: Performance and Scaling

In this interactive workshop style presentation, we'll take a terrible, awful, broken sample site, look at all the nasty ways that its performance is terrible, and fix them, one by one. We'll get the audience involved with suggestions at every step of the way.

All examples will be taken from real life experiences, but no real sites will be harmed in the making of this demo/session.

Lessons Learned from Building a Large Multilingual, Multi-region Site in Drupal 8

Speaker: Stella Power
Track: Site Building

Having recently launched a Drupal 8 website with 13 distinct languages across 4 different regions, this session will take you from the basics of configuring your content to be multilingual through to making it localised in different regions and the various pitfalls encountered and lessons learned along the way.

Estimates are dead, long live forecasting!

Speaker: Mike King
Track: Project Management

In his session, Mike will outline the good, the bad and the downright wasteful aspects of estimates and how they’re used, before contrasting it all with the positive benefits of using forecasting to communicate a range of outcomes and how this can be communicated with the wider team. There will also be a follow-up BoF to share open source tools so that everyone can take home this new set of skills.

Back to the Future: No More Static Mockups!

Speaker: Mark Conroy
Track: Front End

This presentation will be an easy-going rant about how to make things better for frontend developers and will start by taking a look at Photoshop, SketchApp and InVision and how these tools fail to deliver (by building up expectations for clients and problems for implementers). We will then move on to talking about designing in the browser and how tools such as PatternLab and Fractal (basically HTML, CSS, and JS - the foundation of the web) can help solve these problems. Finally, we'll look at how we can (easily) integrate PatternLab with Drupal, thereby going 'Back to the Future'.

Core Accessibility: How are we doing, and what can we do better?

Speaker: Andrew Macpherson (and Théodore Biadala and Kristen Pol)
Track: Core Conversations

As we build Drupal websites, our exposure to the world of accessibility is often driven by the client or website owner. If they have accessibility requirements, we learn about these and try to meet their needs. Sometimes, it's driven by our own desire or need to make our websites consumable for more people.

In Drupal core, we've been making great strides incorporating accessibility best practices into the UX and markup. It’s not only important to help increase Drupal product adoption in some markets (e.g. the public sector) that have strict accessibility requirements, but accessibility is important to make Drupal sites reach the most people with varying backgrounds and abilities. This can be good for business. It is certainly good for our humanity.

Congratulations to Anthony, Stella, Andrew, Mike and Mark on their great achievement. We look forward to seeing these and all the other great sessions at DrupalCon Vienna in September. Hope to see you there!

Nov 21 2016
Nov 21

UX Ireland conference took place at the Trinity Biomedical Sciences Institute, a very modern facility beside the classic grounds of Trinity College. The conference featured a great line-up of keynoters and speakers such as Jon Kolko (author of acclaimed books including “Well-Designed” or “Exposing the Magic of Design”) and Brenda Laurel.

As usual with a conference of this nature, Annertech attended in force, with about 50% of our frontend/design team attending one or both days. I got a lot of takeaways from the talks and workshops: here's a synopsis of them:

Creativity (by involving the whole team in the design process)

The first day started with a great session. Kolko’s “Be the lion tamer: Manage the chaos of creativity” was a joy to watch.

He described how getting the whole team involved in the design process increases creativity. Self-critique is common among designers during the iteration process. Constructively applying that concept to group critique will not only increase creativity but also will make us designers feel better and the rest of the team feel good too. This, in turn, helps to focus and increase trust.

For this to work the designer needs to do certain things: acknowledging feelings, managing ambiguity, letting them run amok, and setting a vision.

His point was interesting on the importance of making the thing first (doesn’t matter if it is good initially) as it will simply start the process and help the team to articulate constraints.

Another takeaway was Jon’s emphasis on rules and how they destroy creativity (unlike the constraints). I really enjoyed the talk, very uplifting.

Design for Scale and Impact

My main takeaway from “Service design at scale: designing for impact” by Oli Shaw was the importance of starting small to lead into the final product. It was very interesting to see how starting with atomic design (and our curiosity to understand the problem) will lead into features (flow, uses cases), the final product and so on.

When (re)designing an interface this is very clear. He gave the example of redesigning a button and how such a seemingly small change can affect loads of different things such as Customer experience, Employees experience, Technology systems, Business processes or even 3rd party/partner business.

As designers we want to prove the value of design, we want to create impact, in one word, we want “change”, because, let’s face it, for us a design “is everything”. He explained the importance of measuring this impact, for us designers to prove our point. Looking at impact has an extra benefit as he said  “looking at how to measure the impact (of a solution) can actually help in focusing on the real problem”.

Understand + Find Patterns + Don't Hi-Fi Everything

I found Denise Burton’s “Design language systems: beware the hobgoblins” one of the highlights of the first day. Starting again at atomic design, I liked her definition of Design Language as the DNA of your brand (what I normally call identity) and her recommendation when creating a Design Language System is to understand that you shouldn’t do it all. Start with the top level nav (for example) and apply to other parts of the design.

Efficiencies and consistency, which are what we want for a good design language system can be achieved by understanding the user, finding patterns and not hi-fing everything. Keeping in mind of course that banality may be an issue if we just “lego” things together, there is a risk of stopping thinking.

Intent for the Good

Day two started with Brenda Laurel and her “Staying grounded in a sea of new 'realities'" key talk which was a history lesson on Virtual Reality that went beyond the present day and into the future. I liked her idea of doing Desig /Research to prove (users) point to the client. It was a very interesting talk.

Yes We Can

Next, I decided to explore the workshops rather than the theoretical sessions and I went to see Matthew Lee running a session about “Research for startups... yes, you can!” which started with an overview of typical research methods (that is, the first half diamond of the first diamond of the The Double Diamond Design Process - not sure I could squeeze the word 'diamond' in there any more!). I really enjoyed how he adapted these to small budgets on what he called research for startups by making it cheap and fast.

He described the excuses clients usually have such us “we don’t have enough money” (Only cost is time), “we don’t have enough time” (one day to one week), “we can follow our gut” (You are not the user) or “my idea is the best” (Humility).

Then Matthew continued with some suggestions on how a guerrilla approach could apply to the startup environment, with ethnographic research/interviews becoming “Field Studies”, stakeholder interviews “Executive Interview”, Focus Groups turning into “Round Table discussions” and Usability Testing becoming “Street Testing”.

A Couple of Workshops to Finish it off

My hands-on experience continued with “ExperienceOps: continuous design in agile teams”, led by Simon Bostock, who highlighted that designers have only a limited amount of control of various elements of the process ranging from an almost 100% control to almost no control. I guess we have to accept that we have no control over certain aspects.

It was followed by another workshop, “Introduction to structured content” by Bonny Colville-Hyde. The first thing I realised as soon as the session started was how much her division of content into taxonomy, content types, fields, paragraphs, etc matches the Drupal world. It was a good session, maybe designers that are not involved in site planning, migration or site building tasks would have found it more revealing.

And that was it.

Overall I think all of the annertechies enjoyed it, I certainly did anyway. As with most conferences, I couldn’t go to all I wanted to. There were really interesting talks by fellow drupalists like Daniel Alb’s “Content is king: the DNA of designing a citizen-centred local authority website for dlrcoco.ie” or Conor Cahill’s “Researching the experiences of people cycling”.

These drupal related talks can possibly be seen again at http://drupalcampcork.com/. If you haven’t registered yet, please do, it is a free event bringing together Drupal developers, themers, end users and those interested in learning more about Drupal for two days of talks, sessions and collaborative discussions. Taking place at Cork Institute of Technology (CIT), see you there.

Nov 18 2016
Nov 18

Man, it's gonna be great!

But then a little voice pipes up: 'It's too complicated! We're trying to do too much! Can't we simplify this?' Nobody wants to listen to the nay-sayer, and the project proceeds apace. In due course, the complicated and extensive nature of the project begins to take its toll. Budgets run dry. Completion dates make a faint whizzing noise as they fly by. And yet the project isn't finished. Cracks appear, bugs sneak through and by the end, you just can't wait until it's over. The love of your life has turned into a horror-show that is slowly leeching the joy from existence.

The little voice, long forgotten, can no longer even be heard.

Let's do things differently! On time, on budget, in scope and on point. Wouldn't that be lovely? One important strategy on any project is the championing of simplicity. For any given item, be it design, feature or content, is to ask: "Can this be simplified? Is it currently over-complicated?"

Simple does not mean Stupid

A simple site need not be one that is devoid of functionality. Nor is it one with an overly simplistic data model or information architecture. It is one which has had the fat trimmed from it; it only includes the elements that are actually needed. Often it is in the identification of the actual needs and the elimination of flights of fancy that the greatest challenge and real rewards lie.

Simple is not Ugly

A simple design will capture the elegance of form, forgoing the unnecessary in the pursuit of perfection. In this era of responsive design, simplicity shines. Single column, full width designs are far more readily made responsive than more complex designs. Accessibility also benefits from simplicity. Naturally, the fewer tricks, hacks and workarounds used to bring a design to light, the more likely it is to be accessible by default. Also, with less thinking needed for the actual design implementation, it leaves more room to build the site in such a way as to benefit the most people.

Drupal is rather opinionated in the way it expects you to build your website's theme. That can be a frustrating experience, if you have not learned how it works. However, imperfect as it is, the theme system is very, very powerful and can actually help a themer to realise that design dream. The simplicity champion says: work with the system, don't fight it. Figure out the Drupal way and make it work for your design. Simplicity lends itself to theme harmony.

Lastly, minimalism as a design school is a beautiful thing, albeit sometimes difficult to achieve. Simplicity strips away the noise from a design until you are left with just the signal.

Simple will not be Useless

Simplicity includes the functionality that people need to get things done. It eliminates the things that people never use. You might look at eye tracking or click tracking data to figure out what people use and iterate your design to improve it over time. Real data from real users is invaluable for this process.

A simplicity champion will also reign in the wilder ideas of functionality: for example, maybe you don't need full, continuous, synchronous communication between your CRM and your website. Maybe one-way communication (i.e. web-to-lead style communication) would actually be sufficient. Or maybe periodic data imports from the site meets all the requirements, in which case the site only needs to be able to export data.

A simplicity champion will not be blinded by a request that comes tightly coupled with a suggested solution, but will reach beyond to figure out the real core requirements and design solutions to meet those.

Simple will be Beautifully Functional

On a massive scale, Google is simple. In effect, it's a one page website with only an input field and then some results returned. But at heart it is beautifully functional. You type in your request, it gives you back suggestions. We love this approach and try to make it work on all projects that we design and build. Take, for example, the www.housing.gov.ie website of the Department of the Housing, Planning, Community and Local Government. A limited colour palette, simple fonts, a simple layout... and a great-looking site that works across devices and transforms what was once a highly complex maze of documents into a very easy to use, information rich asset for the department and all its customers.

Overly Complex is always Expensive & Difficult to Maintain

Complex sites are not only more difficult and costly to build, but this trend continues throughout the lifecycle of the project. With many moving parts, changes need to be planned with greater care and tested far more extensively in order to avoid unintended consequences. Even supposedly simple changes can become large enterprises. Sometimes complexity is unavoidable and that is fine: all these hurdles can be overcome, but it is worth considering the long term effect of your design & requirements choices at the beginning of your project. Your site is not just for Christmas.

Websites Are Like Whiskey

Minimalism is the art of stripping back everything unneeded until you are just left with the core of necessity. In this way, a minimalist site can be thought of like a good whiskey. On the surface, it's simple to look at and made of only a handful of ingredients. But its minimalist appearance belies the depth of complexity present in the process through which it is distilled into being. Skilled craftspeople with decades of knowledge put their love of their craft to use to build you the ultimate product.

Just like excellent whiskey, excellent websites are the product of a process honed over thousands of hours of experience, resulting in beautiful, simple sites that are a joy to use.

Would you like to benefit from our crafting process? Contact us to chat about how we can bring the beauty of simplicity to your project.

Nov 10 2016
Nov 10

Clients sign off on designs. You build a website for them based on these designs. It looks quite like the designs, but not exactly like them. It's not your fault. It's not the client's fault. But wouldn't it be nice if you could build what the client signed off?

Why are the websites we build not exactly like what the client signs off and why is it nobody’s fault? Here’s three (good) reasons:

  1. Websites in the real world use real content – not all titles have 5 words, images have different dimensions, etc.
  2. Designs are in static (image) format so can’t be tested on real devices and screen widths such as phones, tablets, desktops, and smart TVs. So, even though you've got “mobile” designs, they were designed for a specific mobile screen size, but mobile screen sizes can be anything from 3.5 inches to 11 inches.
  3. The designs were completed in my most hated design tool – Photoshop, which renders design elements (especially fonts) different to how browsers do. For example, a thin font in Photoshop might be much fatter in Firefox. Why not just see what it’s really going to look like.

Photoshop is for editing photos (the clue is in the name) not designing websites. If your designer comes to you in 2016+ with designs created in Photoshop, you’ve hired the wrong designer.

Surely there’s an interface designer that is better than Photoshop? There is: SketchApp - built especially for designing user interfaces, but it still falls waaaay short when you want to give your clients designs that they can touch and feel and smell and see exactly what they are going to get. SketchApp is great for rapid prototyping and early stage mockups. It’s great for quickly designing ‘patterns’ or ‘elements’ but not for full designs – again, you can’t expect clients to get a true feeling for how their website works rather than looks by giving them static images of it.

Right, Mark, is there a solution to this conundrum? Yes. It’s called “Design in the Browser” - use the tool that the design will be accessed in to create the design. Give your clients a coded-up prototype. Get your design ideas into code, send your client a link to the website. Let them test it on their phone, on their tablets, on their teenagers’ PlayStations, on their desktops. Let the CEO scream when it doesn’t work on his Windows XP with IE8 as the browser he refuses to let go of. And then explain to him that he wouldn’t have known that if we had sent him a Photoshop document and if he wants it to work on his dinosaur of a machine, it’s going to cost him 30% more. Let him make his decision based on real world interactions.

Do you have a magic workflow that can slay all the dragons?

Here’s my 10 Step Plan for Losing Weight (or at least reducing technical (frontend) debt):

  1. Discovery: see what the client wants.
  2. Research: find out what the client actually needs.
  3. Rapid prototyping 1: use pen and paper, post-it notes, anything to come up with quick ideas about what a design might encapsulate, what a workflow might look like, how an interaction might function.
  4. Rapid prototyping 2: use SketchApp to create quick outlines of what elements of the design might look like (from herein called ‘components’). For example, a search box (input and submit button with bounding border), a news teaser (teaser image, title, post date, snippet, read more link), etc.
  5. Create each design component as an actual coded object. Write the HTML for the structure, the CSS for the layout and styles, and the JavaScript for any interactivity.
  6. Use these design components to create fully-fledged mockups of sample pages of the new website – homepage, listing page, full article – complete with real sample content and images from the client's website.
  7. Send a link to the prototype to the client. This is their designs delivered. Ask for feedback.
  8. Make changes based on client feedback.
  9. Get sign off for the designs from the client.
  10. Use the HTML, CSS, JS from the prototype in the real world implementation of the designs. In short, create a website exactly like what the client was expecting. Not an approximation of it, the thing itself – so the product they get is the product they sign off.

10 Reasons Why Your Client Needs to Insist You Design in the Browser

  1. We use real world content to test that the designs work with the same type of content our clients create.
  2. We can test these designs on the devices they are ultimately going to be consumed on – phones, tablets, desktops, etc.
  3. QA for the frontend begins very early: as the client is signing off the designs, they are signing off the frontend of the website.
  4. QA becomes an on-going item throughout the website build, not something tacked on at the end.
  5. If the client wants an updated design – for example, she would like all text on buttons to be uppercase, we can simply edit the .button class in our CSS and not have to go through 40 PSDs to change each instance of it, saving you time and effort and the client money.
  6. Because we have an interactive prototype of the website, we can use this for regression testing. So, if you add a new feature to the website in Phase 2, you can easily check that the new feature doesn’t break any of the present features.
  7. The client always has the most up-to-date copy of the designs. All they need to do is click on the link you have sent them to see what has changed.
  8. You are providing your client with a styleguide. They can mark this against their print brand guidelines to make sure both are in sync.
  9. When a new feature is requested your client will already have a list of pre-defined design components to choose from. This means you may not need to invent new ones – again, a money saver for the client.
  10. There are no surprises or hidden charges. The client gets what they client is paying for.

I know, I know. This sounds difficult. It sounds like a new way of working. It’s going to take time and effort to implement this workflow. You build websites with Drupal, does this mean you will have to maintain two versions of the frontend?

I come with solutions, not problems. Our tool of choice for this approach is an “Atomic Design” system called PatternLab. This lets us do everything listed above. Using Version 2 of this allows us to integrate the templates that we create for PatternLab directly into our Drupal workflow. What does this mean? Well, without blowing your mind too much, it means that the design that the client signs off is the actual code that is going to be used in the Drupal theme. We do not copy/paste the CSS and JS from one place to another, we do not have anything magic to try to keep two systems in sync. We provide the client with a URL such as styleguide.example.com and they can refer to that as the canonical design as a static HTML prototype while example.com will be the Drupal implementation of it – pulling the templates, CSS, and JS into its system.

Thanks to the great work from the folks behind PatternLab and with some very generous help from the great team at Phase2 who first created a Drupal version of it, we are able to design in the browser, get sign-off from our clients, and then focus on developing the CMS with the frontend work already complete.

Ooooh. That sounds nice doesn’t it? Tune in for part 2 of this series where I’ll detail how to use PatternLab with Drupal. Or, even better, come to Drupal Camp Cork on November 25 and 26 where I’ll be giving a presentation about all of this.

Oct 06 2016
Oct 06

I think I was pretty well prepared and knew what to expect. A couple of blogs from fellow Annertechies had helped to plan it, especially Mark's Get the Most out of DrupalCon Dublin.

Having become a father for the second time only two weeks before the event and spending the previous fortnight on paternity leave, I really enjoyed sharing a full week with my otherwise distributed work colleagues and, shall I say, friends. We even had a headquarters: booth 901, which was only a few steps away from the Drupal Ireland one.


Most of Monday was spent doing the pre-note rehearsal. I must say I really enjoyed being part of it. I had a pretty small part: I was one of the "O'Drupals", the trad band that would be playing a couple of tunes. As the conference took place in Ireland and I knew how to play the Irish drum called the bodhrán, I thought it would be a good way to break the ice.

I also found myself collecting stickers of previous DrupalCons. I have no clue why I did that, I suppose I wanted to go back in time and somehow compensate for my absence in previous events. I guess I wanted my laptop completely covered with these stickers like all the committed druapalists you see at the conference, they seem to have been everywhere! On second thoughts I decided to just keep the stickers, without trying to showcase something that didn't actually happen, so my laptop currently has only 2 stickers: DrupalCon Dublin and one for Drupal Ireland (that I happen to have designed myself).


Tuesday started early. I was there at 6 in the morning for a pre-note rehearsal. The last minute rehearsal went well as did the real performance. I think the O'Drupals played as good as we could have, a trad band consisting of 3 guitars (one of them electric), two bodhráns and an occasional flute here and whistle there didn't feel very traditional to me from the purist point of view, but hey, we did very very well, I think everybody enjoyed the music and we were even sharing the stage with the one and only Dries Buytaert, not a bad place to be when you are at the beginning of the second day of your first DrupalCon.

The highlight of the day for me was probably the Keynote by Dries, right after the prenote, I really enjoyed it. Really looking forward to start using the new D8 Block Placement or Menu settings tray. I think both are really going to affect site builders' usability. Also enjoyed his meaningful moments and how Drupal and its community actually improves people's lives. My lowlight would be "Streamlined Front-end Development with Pattern Lab and Twig", a session that I was really looking forward and that left me feeling like maybe I had too many expectations on this one.

I didn't make it to the welcome party that we, Drupal Ireland, had organised to be on a boat just outside the Convention Centre but I heard the following morning it was a great success and a lot of people went to have a pint of the black stuff with the local Drupal Community.


A mistake (I think) I made was not to attend the BoFs and to go to the sessions instead. "21 things I learned with Twig & Drupal" by MortenDK was the most enjoyable so far. I really enjoyed how he explained how designers and developers are thinking very different and how the themers kind of fall in the middle. By the end of his presentation I felt that I should have really be looking more often into the DrupalTwig Slack Channel and I already decided that I have to go to Frontend United in Athens next May.

It is amazing how much I took in of almost everything he said even though his non-stop presentation style reminded me of a Ramones concert where  songs are played at twice the original speed and one linked to each other with a "one two three four". I have already watched this talk on YouTube again. This is actually one of the good things I found at this DrupalCon. Sometimes there is an overlap of two sessions I wanted to attend: no problem, watch it later on YouTube. Sometimes I want to refresh something in particular as during the DrupalCon there is a lot to take in and energy and concentration levels reduce significantly as the day goes by: again YouTube saves the day.

As happened on Tuesday, I missed the evening side of the Conference. The Realex Web Awards 2016 took place that evening and ireland.ie, a collaborative project between Annertech, Big O Media and the Department of Arts, Heritage and the Gaeltacht, and others which happens to be the first site I worked on in Annertech around nine months ago, was nominated for "Best Arts and Culture" website and "Most Beautiful Website in Ireland" and you know what? It won them both!

And then it was announced that ireland.ie had won one more award, the overall icing on the cake "Best Website in Ireland" award. I felt so proud of my fellow annertechies and rest of the collaborators when I heard the news, it had been a really enjoyable project to work on and it was great to see it rewarded.

And finally, when things couldn't get better, there was one more trophy to collect by Alan, Anthony, Mark, Karen and Tom, my fellow colleagues representing us at the event. They went on to collect the "Web Agency of the Year" award. I truly believe days like these don't come very often, it is such an honour for me to be part of such an amazing team. 


On Thursday I really enjoyed "Creating Layouts and Landing Pages for Drupal 8" by Suzanne Dergacheva and how she explores different theming approaches for landing pages such as using Paragraphs to define the call to actions or create a new content type for the call to actions and reference it with the Entity Reference Field and use the Inline Entity Form.

I also learnt something about DrupalCons the hard way: If you really want to go to something, don't go there just one minute before it starts, don't stop to talk to everybody you know and meet on the way to the second floor. "Drupal 8 hidden power: Entity Reference as a component-based site builder", a session I had been highly anticipating as one not to be missed already had a full room when I arrived, and I was forced to go somewhere else. I know, I can watch it in YouTube afterward, but being there in person would have been A1.

As with the rest of the night events, I couldn't make the Trivia Night but I really wish I had been to this historic occasion. Trivia Night was taking place in the country where it was born: in Ireland. And it was happening in a really astounding venue called the Round Room in the Mansion House. And this is something you can't really watch on YouTube. I will have to wait a full long year and get to it at DrupalCon Vienna.


In general it was a truly enjoyable and memorable experience, much more than I had anticipated. I know I didn't go to all the sessions I wanted to and that I missed the BoFs and most of the social side of the DrupalCon, but meeting great people at the stands, learning lots at the sessions, celebrating the awards and making new friends was more than enough to make it an extremely beneficial week.

I am already looking forward to the next one, it might be even better, at the next DrupalCon in September 2017.

Oct 05 2016
Oct 05

This year's DrupalCon was not different because of the happy coincidence that had Annertech scoop a raft of awards at the Realex Web Awards on the Wednesday (including "Web Agency of the Year"), but rather because of engagement and involvement.

Before the 'Con even occurred, the local team was preparing content, answering questions and, in my case, writing the 24 Hour Guide to Dublin. Seeing my work laid out beautifully in print in the DrupalCon programme was an unexpectedly great pleasure!

As a local, I had the opportunity to MC a keynote Q&A session. That was enormous fun, made all the more fun by a fantastic speaker, Emer Coleman. Coming off stage was a rush, lengthened by the deluge of interaction on Twitter as I was mentioned and our conversation bounced around the DrupalCon Twittersphere.

There was also the personal interest in both other keynotes as Annertechies took to the stage to chat to their speakers - Mark Conroy speaking to Dries at the "DriesNote" and Alan Burke chatting with Eduardo Garcia during the "Community Keynote". Suddenly it was not merely about entertainment any more - I cared. It had become relevant to me. I met Emer on Tuesday, in advance of the keynote, which meant that I was excited about it for most of a day of Drupalcon before even taking to the stage!

The DrupalCon prenote is always good fun - and I was several years in before I even discovered it! This year, taking part in it was very rewarding - from getting to know Jam, Cam, Adam and the crew a bit better, rocking out with the O'Drupals band, endless 12-bar blues in between rehearsals and finally being part of a very entertaining half hour show, I really felt that I was now part of the community. And I definitely made new friends who I'll be looking out for next time!

It was my first time to give a session at DrupalCon, speaking on the topic of "Happiness is ... Remote Working". I had spoken at camps and at Dev Days in Dublin, so public speaking was nothing new. But at DrupalCon, surrounded by my peers, talking to people at the top of their game, in a room full of people far cleverer than I am, it was a brand new experience. Andrew put it best: "Level unlocked!"

Although it was my first DrupalCon speaking slot, I had submitted talks for several years before and it made me think about what I had been doing wrong. Firstly, one must be able to prove that one can speak, so camps, Dev Days, Front End, other conferences and speaking opportunities are all good ways to beef up your speaker CV. Evidently I'd managed to convince the program team that I had cobbled together enough experience. Secondly, I read the track descriptions, and submitted sessions that attempted to deliver the things they were asking for. This is something I had neglected in years past: I would decide on a talk, write it up, and only then read the track descriptions (or even just the name!). Obviously, delivering what the program team wants is the most important hurdle. Here's the video of my talk:

Sep 29 2016
Sep 29

My fingers are trembling typing this. I can't believe it. This morning everyone in Annertech land is thinking "did that really just happen?" It appears it did, we are the web agency of the year!

Last night, to top off the other three awards we won - best arts and culture website, most beautiful website in Ireland, and best website (all for Ireland.ie) - we then went on to win Best Web Agency 2016.

Speaking to accept the award, Alan Burke thanked the great team we have in Annertech and our fantastic clients who trust us with such important work.

Afterwards, Stella Power had the following to say, "it's just amazing. I always knew we had a great team. We work so well together, we get on so well, we're not co-workers or colleagues, we're friends. And when working with your friends it's much easier to do great work. This award vindicates everything we've been doing to make Annertech the agency it is".

Please join me in congratulating Annertech on this fantastic news. Annertech: Web Agency of the Year 2016.

Sep 29 2016
Sep 29

We knew Ireland.ie (built by Annertech on Drupal) was a special website. The design is beautiful thanks to the amazing work of BigO Media, the content, media, and experience is second to none thanks to the the team in the Ireland.ie office at the Department of Arts, Heritage and the Gaeltacht. The implementation is without flaw (if we say so ourselves!).

Last night at the Realex Web Awards 2016 ireland.ie was nominated in two categories: "Best Arts and Culture" website and "Most Beautiful Website in Ireland". It won both. Were we happy? We were ecstatic but that was increased moments later when we won the Grand Prix, the overall winner for "Best Website in Ireland" 2016. Congratulations ireland.ie - winner of three awards!

As well as the above awards we (Annertech) won one more - WEB AGENCY OF THE YEAR 2016. That was just amazing!

Sep 26 2016
Sep 26

We're all very helpful people in the Drupal community and so help should easily be available. But sometimes you get caught out and can't find people nearby - you get lost, you lose your phone, you're in an area of town and haven't a clue how to get back to your home, you are locked out of your AirBnB, you've gone to kiss the Blarney Stone not realising it was 350km away!

If you need help with anything while in Dublin, please get in contact with us. We have lots of local knowledge (and a team of 15 people here for DrupalCon) willing to help you. You can contact us via:

email: [email protected]
email: [email protected]
phone: +353 (0)1 524 0312
twitter: @annertech

We'll be keeping a good monitor on all of the above and will do whatever we can to help anyone that needs it.

Sep 22 2016
Sep 22

DrupalCon Dublin is just around the corner (since I live in Ireland, I mean that literally!). DRUPALCON: HEAR ME ROAR! (or at least speak, along with some other Annertechies). At DrupalCon we'll be speaking on a number of topics (interesting aside: we're the only Irish agency with any speakers at this year's DrupalCon). Here's a quick roundup of our talks and why you won't want to miss them:

Speaker(s): Alan Burke and Aisling Furlong

Where: Liffey Meeting 2 | 10:45

Why come to this: You will learn what large organisations look for when selecting a CMS, how you can pitch Drupal as the CMS of choice, what competition Drupal has and how it fares against it. You do want insights from one of Ireland's largest multinationals don't you?

Speaker(s): Mark Conroy

Where: Wicklow Hall 2B | 14:15

Why come to this: Come get an overview of how to use Drupal as a decoupled system, how to use Ionic Framework (and AngularJS) to take the decoupled data to make a hybrid webapp that can run on iOS, Android, or the native web. Sorry Windows phone.

Speaker(s): Alan Burke

Where: Liffey Meeting 3 | 12:00

Why come to this: Learn from our insights gained building ireland.ie, where we built a co-lingual rather than multi-lingual website. In a co-lingual website all languages present are given equal importance. We made sure this was true on the frontend and the backend.

Speaker(s): Andrew Macpherson

Where: Liffey Meeting 4 | 10:45

Why come to this: Andrew, Drupal core maintainer for accessibility, is one of Drupal's most recent core maintainers. In this core conversation he will discuss the present state of accessibility of Drupal, where it might be improved, and how we can do so. Andrew is the only core maintainer working for an Irish agency.

Speaker(s): Anthony Lindsay

Where: Wicklow Meeting 1 | 10:45

Why come to this: Anthony, Annertech's lead support engineer, works from home (like the rest of us here at Annertech). Come listen to Anthony tell in his own inimitable style why remote working makes him happy.

That's our official speaking slots. Don't miss them, and don't forget to say hello to us at Booth 901.

Sep 20 2016
Sep 20

This day next week, as part of the Drupal Ireland Association, we will be delighted to welcome you to Dublin at the DrupalCon Welcome Party. It's on a boat, which is going to be deadly ("deadly" in this context means great, "lethal" would mean dodgy/dangerous!). The boat is just across the road from the convention centre, so that will be savage ("savage" of course means lots of fun). However, the ceiling inside the boat is only about 2 metres high, that's going to be a bit cat (let's just say "cat" doesn't mean brilliant).

So what is this hoolie (usually a loud party with lots of traditional instruments and improptu performances, but not in this case) all about? It's about the Drupal Ireland Association giving a céad míle fáilte (one hundred thousand welcomes) to the world when they arrive in Baile Átha Cliath (Dublin). It's about us showing gach duine (everyone) that we are a welcoming community of Drupalists in Ireland. That we are open to new people coming on board and helping out with what we do - we'd love to hear from Irish people using Drupal whom are not members of Drupal Ireland yet and also people from other tech scenes here.

The party is on the MV Cill Airne boat (Cill Airne is the Irish for Killarney - you won't be disappointed if you go there - and means the "church of the sloes"). It's starts at tea time (18:00) and goes on until serving time finishes (23:30 on a Tuesday). Come join mise (pronounced misha, means "me"), all the rest of the Annertech team, many others from the Drupal Ireland Association, and hundreds (sorry we can't fit thousands onto the boat) of other Drupalists at the DrupalCon Welcome Party to have a savage, deadly night of craic (fun).

Sep 15 2016
Sep 15

Choosing proper hosting for your site shouldn't be a race to the bottom.

Hosting websites is hard. Websites themselves are complex, global traffic can mean huge numbers, big spikes in activity and always demanding users. Sites need to be served quickly, consistently and reliably. Downtime costs money, effort, and more than likely a few extra grey hairs too.

Choosing hosting for your website can be a daunting prospect. You've invested time, effort and money into developing your creation, of which you are justifiably proud. Now you need to find it somewhere to live. But where?

Hosts come in all shapes and sizes, from cheap shared hosting environments for about a euro a week, up to specialised infrastructure platforms catering to massive distributed applications.

Here at Annertech, we offer expert, Drupal-optimised, managed hosting.

  • Expert because we know Drupal inside out. Expert because the server administrators are at the top of their game, using best-in-class tools and technology to provide rock-solid and reliable infrastructure for your sites. Expert because our hosting utilises the power of version control and provides development environments identical to your live setup, to maximise confidence in any changes. Expert because we are the only agency in Ireland with a member on the Drupal security team.
  • Drupal-optimised because our hosting comes tuned to get the best out of Drupal, and is bundled with all the performance enhancing extras you can imagine such as caching layers and reverse-proxy engines.
  • Managed because you don't need to worry about server software updates, application layer updates, server configuration, or any of that jazz. Managed because, importantly, we take care of all your Drupal core and contributed module security updates for you.

Security updates alone make this arrangement make sense.

For example, take a site with, say, 100 contributed modules. You could reasonably expect to have to deal with around 20 security updates during a year. Monitoring for security releases, applying updates locally, deploying to a test environment (you have one of those, right?), testing, and then replicating those changes to the live environment all takes time. Then there's all the server level software updates and patches. That could turn out to be a lot of headache.

Maybe you have a support contract with some lovely developers (hi!) who do your security updates. That's a great way to handle it, but wouldn't it be even better if your developers spent their time improving the features of your site?

Simply by hosting your site with Annertech, security updates become a non-issue. Saving you stress, time and money.

Give your lovely new website a nice, secure place to live. Talk to us - you'll be glad you did.

If you'd like to discuss hosting face-to-face, we'll be at Booth 901 at DrupalCon in Dublin.

Sep 13 2016
Sep 13

Annertech will be descending upon DrupalCon with (nearly) our full team of "Annertechies". So much so that there will be more Annertechies in attendance than all other people from Irish agencies combined. With that kind of showing, we thought we'd introduce ourselves and let you get to know us.

Stella Power

Stella is Ireland's Drupal wunderkind. Founder of the Drupal Ireland Association, member of the Drupal security team (the only person from an Irish agency with that accolade), and managing director of Annertech, Stella is the kind of person that doesn't come along often enough. Stella has spoken at many European DrupalCons; this year she was track chair for the business track and is also the local liaison for DrupalCon.

Alan Burke

Alan is also a director of Annertech. When not keeping the invoices raised and paid, he's focussing on being a top-notch frontend developer. In this vein, his main passion is for website performance. Alan has spoken at a lot of DrupalCons over the years; this year he will be speaking about developing a co-lingual website for ireland.ie and why a multinational organisation might choose Drupal.

Dermot Frost

Poor Dermot has a tough life. He won't be able to make it to DrupalCon as he'll be preparing for a conference the following week in Boston. When not jet-setting, Dermot spends a lot of time building and maintaining server infrastructures.

Anthony Lindsay

Anthony is our lead support engineer. He makes sure that all our existing clients are happy. For Annertech, support often means on-going development of new features and enhancements to existing ones. If you have an existing website and would like us to support it, come talk to Anthony at Booth 901. This year he will give a presentation at DrupalCon about how remote working makes him happy.

Mike King

Mike keeps us all in check. He's our project manager. He makes sure we know what the client wants and deliver it to them on time, on budget, and with smiles on our faces. He was track chair for DrupalCon this year on the project management track.

Mark Conroy

Mark - me! - is a lead frontend developer with Annertech. He's very interested in maintainable code, design in the browser, component-based frontend, and how those three can be brought together. You can find him (too) often in the DrupalTwig slack. He'll be presenting at DrupalCon about getting started creating mobile/hybrid apps using Drupal as a backend and Ionic Framework as a frontend. Mark is presently chairperson of the Drupal Ireland Association.

Tommy Lynge Jørgensen

Tommy is one of our lead backend developers. He knows a lot about solr, and migrations, and backing up data. He comes from Denmark, lives in Ireland, and is the reason we have cake at Booth 901. Come for the code, stay for the cake!

Andrew Macpherson

Andrew is another lead backend developer in Annertech. He is the only core maintainer working for an Irish agency, having recently been made a core maintainer for accessibility. So, if you want an accessible Drupal website built by an Irish agency, get in contact with us. He will conduct a core conversation on the future of Drupal accessibility at DrupalCon.

Gavin Hughes

Gavin is one of our support engineers. Whilst Anthony makes sure that all our clients are happy, Gavin is the one beavering away in the background actually doing the work!!! (Sorry Anthony!) When not debugging issues and developing new features, he's probably kite surfing somewhere off the west coast of Ireland.

Bren Vaughan

Bren joined us recently as a project manager. Having trained as a developer, he is slowly recovering from his past life. He's also slowly recovering from participating in Iron Man competitions and other feats of endurance unknown to the rest of Annertech. He's got so much recovery to do, he won't make it to DrupalCon this year.

Ricardo Flores Galán

Ricardo, from Spain, is our in-house designer and UX expert. He checks the fine details of designs for consistency, brand adherence, vertical rhythm, and more. Oh, and his wife gave birth to a beautiful baby boy yesterday. CONGRATULATIONS. Ricardo is presently secretary of the Drupal Ireland Association.

Rob McCreary

Rob lives in Northern Ireland. He joined Annertech almost a year ago and has been doing some fantastic frontend work for us. Previously having worked in the non-profit sector he is a great compliment to many of the types of clients Annertech has historically serviced.

Adrien Sirjacques

Adrien is one of our backend developers, and has worked on a number of projects to add new features to existing sites and also some greenfields work. Though from France, he's very active in the Irish Drupal community and can be found each month at our Drupal Ireland meetup in Dublin.

Tom Bamford

Tom is English. He lives in France where he attends to the meadow, country walks, sunshine (which apparently is rare in Normandy) and frontend development. We're lucky to have him on board given his vast knowledge of Drupal, JavaScript, SASS and other complimentary items.

Karen Leech

Karen is also English. She also lives in France, and attends to the same things as Tom. Except, instead of frontend development she is a site builder and QA Analyst. You know when you miss out on a client request by just a tiny item? Karen is our backup to notice that and makes sure nothing gets to UAT without passing her exacting standards.

So that's it. A quick roundup of the Annertechies you'll (likely) meet at DrupalCon. We'll be at Booth 901 and here's some reasons why you should come talk to us.

Sep 08 2016
Sep 08

DrupalCon is big. It's got hundreds of sessions. A similar amount of BoFs. Approximately 2,000 attendees. Social events left, right, and centre. It's not hard to get confused, miss things that you promised not to, and leave thinking "damn, I could have done that better". At Annertech, we're Ireland's most seasoned DrupalCon attendees. Here's our guide to making the most of it.

Create a Schedule

You can add any session to your own personal schedule on the DrupalCon website. You can do this right now. Do so. With so many great sessions running concurrently, it's very hard to work out on the spot what to go to next. You can find your personal schedule here.

Attend BoFs

At my first DrupalCon (in Prague) I went to the all day media sprint on Friday. I can't explain how much I learned that day - amazing. It was then I realised that I had missed out (and it was too late) on great opportunities by only going to sessions during the week. BoFs are where you get down and dirty with the innards of Drupal and related technologies and theories - accessibility, Drupal for Museums, Open Data, etc were just some of the ones I attended in Barcelona last year.

What's a BoF? It's a "birds of a feather" meeting. Basically, people with a common interest book a room and sit around discussing it. It's usually someone with A LOT of knowledge about a topic that does so. The format is very informal and friendly, just like a tutorial in college, with usually less than 20 people in attendance. This year I'll end up at about 50% BoFs and 50% sessions (or less).

Go Easy on the Alcohol

Yes, we know, you're in Ireland and Irish people like to drink and party. That's true, but you're going to be here for a week. Please don't go overboard on Monday and be wiped out for the rest of the week (not least becuase my session is on Tuesday and I'd like to see you there!).

During the week there will be lots of social events. You are welcome to all of them. But do not feel pressured to drink alcohol or to buy drinks for others. Be respectful of yourself and others and when leaving venues please do so quietly - there are lots of people trying to sleep.

Attend the Keynotes

If you go easy on the alcohol, this one is easier to achieve. The keynotes are where you'll learn about the state of Drupal and the plans for the immediate future of it from Dries. This will be followed by a Q&A with Dries, moderated by a local volunteer, where you get to tweet questions to him.

The other two keynotes will be hugely relevant talks from very respected individuals - Emer Coleman and Eduardo Garcia.

Contribute to Drupal

There will be loads of opportunities to contribute to Drupal by sprinting and/or mentoring. There will be extended sprints each weekend before and after DrupalCon. The conference hotel will have a 24 hour sprint room. Contributing is how Drupal gets built. Please contribute.

Take Time Out

With all the talking and sessions and BoFs and keynotes and contributing, it's okay if your brain is feeling a little over-worked. We have a beautiful city in Dublin. Take some time out, go for a walk. Visit some our recommended things to see and do in Dublin. Talk to some locals. Enjoy yourself (DrupalCon is about more than just work).

And if all that fails to help you get the most out of DrupalCon, well, you could just go on the DrupalCon diet!

Jul 25 2016
Jul 25

Yesterday all the accepted sessions for DrupalCon Dublin were announced, and we are delighted to report that 5 of our 8 session proposals were accepted! With Acquia being the only company receiving more acceptances, we are extremely proud of our achievement.

Testament to our high standing in the Drupal community, we are the only Irish company speaking at DrupalCon Dublin. Our accepted sessions this year span a number of different tracks, namely Business, Horizons, Site Building, Being Human and Core Conversations, and cover topics from accessibility to remote working to building mobile apps with the Ionic framework. Congratulations to all our speakers!

Here's a quick run down of each session.

Building a co-lingual website - lessons learned from ireland.ie

Speaker: Alan Burke
Track: Site Building

2016 marks the centenary of the 1916 rising in Dublin, a pivotal year in Irish history, and is marked with a series of high-profile events commemorating the rising. ireland.ie is the official state website for the 1916 commemoration and runs on Drupal 7.

While English is the main language in Ireland, Irish is the first official language. A decision was taken to present both languages side by side wherever possible for the 1916 commemorations - including on the website. This session will focus on the unusual co-lingual [2 languages side-by-side] approach, and how Drupal made it possible. 

Choosing Drupal - insider advice from an Irish multinational

Speaker: Alan Burke & Aisling Furlong from Glanbia
Track: Business

Struggling to sell Drupal to clients? Ever wondered what goes into the decision making process when choosing a CMS?
In 2014, Glanbia selected Drupal as the CMS of choice for marketing sites. This session will outline the decision-making process used, and what Drupal agencies can learn when pitching Drupal. This is a joint session proposal between Annertech and Glanbia.

Bridging the PhoneGap: Getting Started Creating Hybrid Mobile Apps with Drupal and Ionic Framework

Speaker: Mark Conroy
Track: Horizons

With the advent of hybrid mobile apps, you can continue being a Drupal frontend developer and also build apps without needing to learn new technologies. The mobile web is quickly catching up with native apps. The mobile web is free, and open, and available to all of us right now and doesn't bind us to proprietary systems. With the many advances being made in this area, we can create great mobile experiences for users.

Future Directions for Drupal Accessibility

Speaker: Andrew Macpherson
Track: Core Conversations

Drupal has made great advances in accessibility over several major releases, and nowadays ranks as a leading implementation of web accessibility standards.  This session will encourage contributors to look ahead at future challenges and opportunities for accessibility during the faster 8.x (and 9.x) release cycle. 

Happiness is... remote working

Speaker: Anthony Lindsay
Track: Being Human

Many Drupal agencies have remote workers. Some are entirely distributed. Whilst remote working is beneficial to all concerned in so many ways, it does come with its own challenges. This talk will cover the journey I took when I moved from a typical 9-5 office job and joined Annertech, which is an entirely distributed Drupal agency. It will highlight the challenges I found: the good, the bad, the funny and the downright surprising, and offer as examples, my experiences for staying happy and healthy in what has the potential to be an isolating environment. 

Congratulations to Alan, Anthony, Andrew and Mark on their great achievement. We look forward to seeing these and all the other great sessions at DrupalCon Dublin in September. Hope to see you there!

Jul 23 2016
Jul 23

Ever since Andrew joined Annertech, he's been a champion of accessible web design and has ensured that accessibility has remained a key focus area in everything we do. That combined with his dedication to open source and contributing back to the community, meant that we were not surprised when he was asked if he'd be interested in becoming a Drupal core accessibility maintainer.

Andrew is truly passionate about accessibility and has increased the knowledge and awareness of issues encountered by people with disabilities for all members of our team. We can not think of a better candidate for a new Drupal core accessibility maintainer.

His response when asked to be a Drupal Core maintainer?

I was really stoked when Mike asked if I'd consider becoming a core maintainer. I have barely stopped bouncing around my home.

Congratulations from everyone in Annertech Andrew!

Jul 01 2016
Jul 01

With three months left to go before DrupalCon Dublin, event planning is in full swing. Like all Irish Drupal events, Annertech are actively involved in preparations for DrupalCon. Our managing director, Stella Power, has taken on the role of local team lead as well as Business Track chair, and I myself am the Project Management track chair. There's less than a week now to get your sessions submitted for DrupalCon, so it's time to get writing!

Business Track

This year the business track is focusing on how agencies can grow their business and how to do so sustainably. We're looking for speakers who are willing to share their experiences and insights into growing their businesses, what worked, what didn't, and why.

Suggested topics include:

Marketing Drupal

Competition in the marketplace is growing, both from a growing number of agencies offering similar services, but also from alternative solutions being offered. We are looking for sessions on how you generate new leads for your business, and how you market and postiion Drupal and your agency as being the best solution available.

Going for Growth

Growing your business is all very well, but how do you manage this growth and ensure you have the necessary structures in place to ensure this growth is sustainable. We are seeking strategies which offer sustainable approaches to growth for the small and large Drupal agency alike.

Business Innovation and Diversification

Perhaps the solution to sustainable business growth is to innovate and diversify your service offering. Maybe you need to consider extending into additional or alternative markets or verticals. But when is the time right to do this? And what are your strategies to approaching this?

Drupal 8

With the release of Drupal 8, there are a number challenges, but also opportunities for agencies working with Drupal. What has been the impact of Drupal 8 on your business, on demand for your services, on your sales or marketing processes and on your team? How has it affected the estimation and delivery of your projects? How do you convince clients to upgrade to Drupal 8?

These are just some of the ideas we have for the Business Track this year. We want to hear from you, about your experiences and insights into the above topic areas. Got an idea for another session? Great, then let us know and submit it!

Project Management Track

Whatever the size of the project, no matter how many people are working on it, it will need to be managed. Some have dedicated project managers, others share the task within the team, whatever way you spin it it's got to be done, so why not make sure we can learn how to do it in the most appropriate way.

The focus is about sharing your experiences, good or bad, as long as you learned something which is relevant to others, you're welcome to submit a session, here are some topics which we're actively looking for:

  • Tips and Tricks: How did you improve your processes or learn how not to do something?
  • Becoming agile: How did you become more agile?
  • Getting the numbers right: Estimations, budgeting and reporting. How do you keep on top of things?
  • Freelance Project Management: Are you, or have you ever been, a freelance Project Manager? Tell us your story.
  • Managing an Open Source Project: Ever been involved in managing an open source project? How did you get by? Would you do it again?

As always, if you're unsure whether your session proposal is appropriate, reach out to myself or Stella and we will help you where we can.

Countdown to session submission closing starts now, are you ready?

Jul 01 2016
Jul 01


We were already prepared for a scenario like the Aberdeen Cloud breakdown, owing to our disaster recovery plan. Fortunately we didn't have to set it in motion. Each night we have a simple script which takes off-site backups of all of our hosted sites. We've made the source code available on github, so hopefully this will help others prepare for the likes of the Aberdeen Cloud implosion, and perhaps we can share ideas on how to improve each other's disaster recovery plans.

Our experience with the Aberdeen Cloud incident

We have a large number of sites hosted by various cloud services. Since autumn 2013, we'd mainly used Aberdeen Cloud, and in autumn 2015 we started to explore other options to see what else the market had to offer. Platform.sh was the one that we decided to give a serious test for new clients.

Soon after that, Aberdeen Cloud began to seem a bit flaky. Longer response times on support tickets. Solr services started to fail, along with random outages of various other services. We accepted that for a while, but after having lost and regained SSH access to all of our sites (including git and rsync), we eventually decided that enough was enough and we couldn't put our trust in them anymore.

We had to migrate everything to alternative hosting platforms. Given the similar price points and the fact that they seem well funded and offer excellent support, we decided on Platform.sh. And so began Project Exodus. 

Over the next three weeks we migrated over 20 sites to Platform.sh in a staged approach. I wouldn't say that it was a straight-forward process. Lots of clients had specific quirks to their setup. For example, some needed a PHPBB forum, others had FTP access for uploading files, some integrated with external systems that required firewall changes, etc, while others had custom .htaccess redirection rules that needed to be rewritten for Nginx. However, we were very lucky and had completed Project Exodus nearly a month before Aberdeen Cloud finally came tumbling down.

So what if you were not as fortunate as us, and still have sites whose assets are no longer accessible? Stuck in cyberspace, or maybe just plain deleted?

Well, I'm not sure there is a lot you can do. Maybe read Code Engima's blog post about the different things they've tried. However, to put it bluntly, it sucks! Enough said about the matter.

Now it's time to ensure you're never caught out again.

But what can we do to prevent this from happening again?

All companies probably have their own way to deal with this kind of scenario, but I'll tell you about how Annertech deals with backups and recoveries.

We have two sets of backups. A backup from each day, for each production/live/master environment, which is hosted by the cloud service. Then there is an off-site backup (again, daily) used for disaster recovery. The latter one is the important one in this scenario.

The idea is that even if Amazon (which hosts Aberdeen Cloud services) pulled the plug, we would still have access to our clients' data.

We have a server, hosted by a different company, that: 

  1. Pulls down a copy of the database, from every cloud-hosted site, every night, and saves it for four days, before it deletes it again.
  2. Runs `rsync` on every cloud-hosted site, to get an up-to-date version of the files folder, every night.

Sounds simple? It is. All it requires is that your hosting partner supports running Drush on your remote sites and you're good. If you run Drupal sites, and your hosting partner doesn't support running Drush on the remote sites, find somebody else who does. It's that important!

Regarding the code for the sites; we keep our source code repositories on dedicated git services. And, more than likely, we'll also have a copy or two on developers machines.

I'd like to show you the two backup scripts that I made, one for Aberdeen Cloud and one for Platform.sh.

The code is meant to work in our setup only, and is not (yet) generic enough to just work out of the box elsewhere. The release of the scripts is meant to give you a leg up and some inspiration. This is by no means the final end point for these scripts - we are continually evaluating and improving our system, and I look forward to hearing what ideas you have on where we could take it from here too.

The entire repository of code can be "stolen" from github.

When you have a disaster recovery plan you also need to make sure that it actually works. You can do this by downloading the latest backup from each of your sites once a month, installing and then testing them. I've tested a site, where the DB file was corrupt, but only for that site, so make sure that you test all of them. The setup of test sites can also be automated by a script so you don't have to setup 10, 50, or 300 sites and test each manually. Scripts are your friends. Make good use of them and have them do all the hard work.

Now, if you really want to push this further, you should implement a "Smoke test" in all of your installation profiles, so that you can trigger that to see if the site is alive; or perhaps tie it in with a Jenkins server.

If something is unclear, feel free to put a comment below. If you feel like this could be improved, feel free to contribute with a pull request. We are all ears.

Mar 29 2016
Mar 29

You're working on a client's existing site, and they ask for some new functionality. Your first thoughts are: "Yay, some work!" Quickly following that you think: "What do they want? How am I going to build it?" The often unasked question, however, is "How can I integrate this new functionality with what they already have, without making maintenance a nightmare, or even worse, impacting existing functionality?"

This is a tough ask, as the new feature has the potential to reach across multiple pages, content types and styles.

We can build it!

For simpler features, it's easier to confidently introduce the new parts. For example, if your client wants a blog, you know that you can create a blog content type, give it an image field and a taxonomy reference field for tagging, and you're almost done. Build a couple of views displays and wrap the lot up in two features. One hook_update_N() function later and you have a scripted deployment to add your new blog articles, listing, tags and menu items in a single  drush updb command. Easy, right?

But even with this simple example, what about theming?

The example assumes that there's no particular theming requirements for the blog articles and listing, and that the theme will handle all of the elements gracefully. But if changes are required, how do you prevent inadvertent CSS bleed from new style rules over into existing content types. Equally, if new styles are introduced, should they apply elsewhere on the site? Should, in fact, any new blog-related CSS live in the module layer, with the definitions of all the functionality, keeping all the related code together? Or should we dive into the theme and add styles that would become redundant if the blog were ever deprecated?

These questions deserve consideration, and I fear that they are often ignored, with a blasé "of course CSS goes in the theme!" attitude.

There is evil there that does not sleep.

Let's talk about Webform.

The Webform module is amazing. It is really powerful and allows site builders and site managers/editors to quickly craft complex forms for capturing and storing data, reporting on that data and even allows limited workflow functionality.

But for many business cases, the out of the box functionality simply is not enough. They want to be able to take payments and to sell things - tickets, time, etc. They want to be able to prepopulate fields with values and modify form elements based upon other field values.

Now we need to start really thinking.

We can modify form elements with hook_form_alter() - that's fine. But how do we limit it to webforms? OK, we can use the Form ID - it has the form 'webform_client_form_NID' so we can look for that. But each webform has a different numerical ID, so how can we limit our customizations to just a certain form, or a certain subset of forms? This is where we can get messy and we need to remember that this functionality is for life (well, the life of the project), not just for Christmas. However we do this, it needs to be maintainable.

Possible solutions.

If we want to identify a single specific webform, we can use its Node ID, which is an obvious choice. We can put that NID into a variable and into settings.php, which avoids hard-coding the NID into the functionality. The drawback of this method is that NIDs can change between environments, so your donation form might have a different NID on your development environment than it does on the live environment. This, at the very least, complicates deployments.

If we want to modify a subset of webforms, maybe we can use a content type. For example, Webform can be attached to any content type, so we can easily create a 'donation form' content type and make our modifications to any webform of type 'donation form'. In this way we can manage separate functional modifications to other forms, e.g. event registration or lead generation. This too works, up to the point where the site owner wants to combine both your donation/payment functionality and your event registration functionality into one form. How does one rationalise and implement such a request? And how do you then limit this combined functionality to specific forms? Are we back to square one with node IDs set in settings.php, and its attendant maintenance nightmare?

There has to be a better way.

I quite like to use fields to bring configurability to new functionality. A couple of fields in a vertical tab field group lends a nice air of a proper settings form to your node edit page. Once you interrogate your node for the values of these settings fields, you can then control your custom functionality at a per node level, which is a really neat thing to be able to do from both a site admin and site maintenance point of view.

The problem here is that you've two separate items that are tightly coupled: your nifty new module/code and field configuration updates to any content type that you want to make use of it. You then need to bear in mind that you need to maintain the Features for any such content type. It would probably be worth bringing this logic to its natural next step, creating a Feature for all the Field Bases of your new fields, guaranteeing that they exist and are consistent with the machine names expected by your custom code (and more easily allowing field bases to be shared across content types/features without conflicts).

Somewhere, over the rainbow

Here's my version of the Holy Grail: imagine a system where you could indicate on a settings page, which custom functionality should apply to which content types, and settings controls would then magically appear on the relevant node edit forms... As of this writing I have not seen a working model of such a system, but I can dream.

Maintenance of your site should never be far from your thoughts when introducing new features/functionality. As Support Lead for Annertech, I have to deal with a lot of legacy code, and therefore think about these things a lot. If you'd like to chat about support for your Drupal website, or ongoing development in a sustainable, maintainable way, give us a shout.

Feb 26 2016
Feb 26

Oxfam Ireland wanted a faster site. It was already pretty performant, especially for a high traffic site, chock-full of features, but with the ever upward march of mobile usage, performance rose to the top of the want list.

Why do you want a fast site?

The reasons are many, and often not even on a site-owner's agenda when planning a site. Here's a few:

  1. Slow pages cost you conversions (AKA money!). Research back in 2006 by Greg Linden showed that every 100 millisecond delay in page rendering time resulted in a 1% loss of sales for Amazon. 
  2. Google prefers faster sites, so it impacts on your search rankings
  3. If you're on a mobile device over a dodgy connection you just aren't likely to hang around waiting for a slow page to load. Face it, you'll get bored and load up Twitter instead.

What counts as fast?

How fast is fast? Well for that matter, what counts as a page load? When is it 'done'? There's lots of tools and lots of metrics. e.g.

  • Actual time to finish loading a page
  • Time to first byte i.e. when the first packet (piece) of information hits your browser.
  • Time to usable - this is where everything on the page is not loaded, but there's enough core content there to keep a user happy while the rest finishes downloading.
  • onLoad event - this is a Javascript event that fires when all the Javascript is loaded and therefore all the bells and whistles should work.
  • Perceived performance - this is more nebulous, but arguably the most important thing to consider. How fast does the site feel to the user? Does the important stuff at the top load quickly and first so they have something to look at? Can you click around whilst the rest loads?

We've done a bit of a deep dive on performance testing here, if you want to know more. 

How we made Oxfam's website faster

Performance is not binary. There are a lot of variables to consider. When speeding up oxfamireland.org, we took a three-pronged approach.

  • server infrastructure.
  • Drupal tuning
  • a home-page redesign.

Each of these avenues of attack improved matters and each one worked in tandem with the other two to achieve measurable, demonstrable speed improvements.

Server Infrastructure

This was arguably the easiest improvement to implement. We moved the site from a dedicated, generic, virtual private server to our high availability, high performance platform. Tuned specifically for running big Drupal sites, our hosting environment comes fully loaded with a Varnish reverse-proxy server and Redis (an advanced key-value store) for lightning-quick server response.

In addition to simply putting the site on our platform we also made a few changes at Apache level, to better serve certain elements of a page, for example, compressing SVG files as they were served.

Drupal Tuning

Within the guts of Drupal we found plenty of small wins. We:

  • disabled some unneeded modules.
  • deleted other modules that had found their way on to the site but remained unused to reduce the amount of PHP that had to be parsed.
  • isolated and solved small, otherwise inconsequential PHP errors and notices to relieve pressure from the database
  • minified HTML, JS and CSS to reduce page weight
  • moved as much JS as possible to the bottom of the page so that it would not block other elements from loading
  • ensured that no modules were setting unnecessary cookies that might interfere with Varnish

Home Page Redesign

Home pages are notoriously heavyweight. Typically, home pages tend to have rich multimedia experiences, laying out a site's wares up front in the hope that a user can easily navigate to any part of the site from there.

Heavy pages take ages to load. Pages with lots of images take longer to load. High resolution, uncompressed images squished into a carousel/slider exacerbate slow loading. Throw in a good helping of Javascript and you're unlikely to see your page load this side of the weekend.

Whilst we wanted to improver overall load time, the real win was to improve the perceived usable state, i.e. the time to having usable content presented on the page and bring that down as low as possible.

With the home page redesign, we had the following aims:

  • Reduce the number of page elements. In terms of designing for speed, less is more. So fewer images, fewer styles, less Javascript, etc. Every added element will have a performance impact.
  • Following on from this, reduce the number of HTTP requests. Every HTTP request involves the overhead of a round trip from client to server and back again. Fewer requests means a faster page.

Drupal allowed us to combine CSS files and Javascript files to minimize their numbers and squish them through minification and compression to reduce their file-size. We looked into using image sprites and better using image-styles in order to optimize both the actual size and file-size of images.

The single biggest change was in getting rid of the hero image slider on the home page. This single element involved multiple large images and simply by removing that, it allowed a single smaller masthead image and text to load quickly and efficiently at the top of the page, so that it is the very first thing a user sees. This gives the perception of a really lightning fast site.

So how did we do?

The combination of all these techniques, each one a small gain, led us to a very nice 15% increase in overall page speed and more importantly, a massive 50% improvement in time to perceived usable state.

In an organisation where performance directly relates to numbers of donations which in turn directly affects the lives of the poorest people in the world, every millisecond counts.

Nov 19 2015
Nov 19

Drupal 8, which we previously called "the most brilliantly amazing responsive accessible version of Drupal to be released so far", has just been released.

This is major news for three reasons.

  1. Drupal 6 will not be supported for very much longer. If you are running a Drupal 6 website, you will need to start migrating to Drupal 7 or Drupal 8 (or risk potentially being exposed to security vulnerabilities and loss of data).
  2. Drupal 8 comes with lots of great features built into its fabric. This will make it the most enjoyable Drupal ever for content editors.
  3. It will be the most advanced CMS on the market, bettering all open source and proprietary systems.

When you involve Annertech in your Drupal 8 projects, you will be in very capable hands as we are the only team in Ireland:

  • to have committed code to the Drupal 8 codebase
  • to have live Drupal 8 websites launched already
  • to have a member on the international Drupal Security Team, ensuring that your website's data is safe

When it comes to Drupal 8, we are as excited as we are experienced.

Your Project + Drupal 8 + Annertech = Success

Get in contact with us today to find out more.

Oct 19 2015
Oct 19

Technical debt occurs when you take a shortcut, thinking "this will do for now. I'll sort it out properly later." And then you keep putting off "later", and probably forget about the issue ... until it comes back to bite you.

It's all those tiny things like a misspelled variable, whose misspelling has to be replicated evermore, or making a configuration change on a live site without capturing it in code, so that the live site is now different to the development one.

It's going [copy]-[paste] to a chunk of code when you really should be abstracting it into its own function.

It's neglecting coding standards. Even 'just this once', making your code harder to read and understand.

It's adding a */


About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web