Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Mar 26 2024
Mar 26

Why are councils turning to Drupal? 

Weighing up which CMS to choose is one of the most important decisions an organisation can make. For councils, there is a need to go with a CMS that works, that has the features that councils need and, crucially, one that is secure. 

Choosing the wrong CMS can set you back in terms of time, money, and frustration – and it’s a decision that you’ll be stuck with for years, usually, especially if you’re locked in to a specific vendor. LocalGov Drupal is a CMS that is built on Drupal, so the code is freely available, which means no vendor lock-in. But, most importantly, it has been created by councils for councils, who share code, user research and ideas. 

Its numerous benefits include: 

  • Reducing time and resource-intensive tasks of redesigning and rebuilding platforms. Instead, councils use a platform that other councils have already built to meet business objectives. 
  • Sharing knowledge and practices with other councils that have already solved many common problems through LocalGov Drupal. 
  • Accessibility – LocalGov Drupal is WCAG 2.1 AA compliant out of the box. 
  • Cost-effectiveness – councils save up to 80%. In addition, because it is built using the open-source CMS, Drupal, there are no licence fees involved. 

Annertech’s Director of Development Mark Conroy has been involved with LocalGov Drupal from the beginning. 

“LocalGov Drupal has enterprise-ready features, a robust theming system, and no licence fee. It is proving itself to be the most cost-effective way to develop council websites. Backed by a slogan of ‘by councils for councils’, there is no other CMS or project like it on the market.”  – Mark Conroy

Colin agrees, saying that “LocalGov Drupal appeals to councils because it has been developed by councils for councils, so specifically meets their needs”. 

“It is also perhaps due to the potential cost savings and to the growing functionality,” he said. 

This functionality is constantly improving as more councils join the LocalGov Drupal family, and use budgets that they would have used on development or licences on new features and improvements. The LocalGov Drupal project also aligns with the Irish government’s Build to Share initiative, which forms part of the Irish government’s “Better Public Services, the Public Service Transformation 2030 Strategy". 

Its goal is for the public sector to share code in order to save valuable resources like time and money. 

“The other thing that stood out from this new research is that the number of CMSes being used by councils is reducing as more councils are moving to the more popular CMSs (Drupal, Jadu, Umbraco, GOSS iCM and WordPress),” said Colin. 

The more popular the CMS the more features and support they tend to offer.

Mar 21 2024
Mar 21

The LocalGov Drupal community is getting together for a day of networking, learning, and socialising, and Annertech will be there too, as the headline sponsor. It’s the first-ever LocalGov Drupal Camp, and its theme is “How collaboration can help bridge the capacity and resource gap”. 

Annertech has been involved in the LocalGov Drupal project – a Drupal-based CMS created by councils for councils – since the beginning. 

The code was initially developed for Brighton and Hove City Council in 2018, and was made available for any council to use free of charge. Councils can use the budget they would have spent on this code on developing new features for LocalGov Drupal instead. And any new features that are developed are in turn made available to others. 

LocalGov Drupal Camp will see the community who made this project possible – representatives from councils, public sector organisations and agencies, content designers, product managers and developers – gather to share knowledge, experience and help overcome the challenges they all face when it comes to creating excellent websites for councils. 

Annertech has been proud to be associated with LocalGov Drupal, and we’ve helped many councils – both in the UK and Ireland – move their websites on to this ground-breaking platform. 

Jan 12 2024
Jan 12

LocalGov Drupal is a CMS created by councils for councils. It is the perfect example of how, by pooling their resources and sharing code, local governments can save money and have brilliant websites that better serve their communities.

It's a project that means a lot to us at Annertech, and we have worked with many councils, designing new websites, creating new features for them, and then experiencing the thrill of these new features being made available to other councils to use.

We've been working with LocalGov Drupal (LGD) for a few years now and are proud of our contributions to the project. The past few months have been really productive for the Annertech team's LGD offering – we've developed new features, created new tutorials, and more.

Open Digital Cooperative

Our Director of Development Mark Conroy has been involved with LocalGov Drupal since the project was in its beta phase. Mark is the project’s front-end lead, developing the theme and working with many councils to ensure that their websites look the way they want them to look.

Towards the end of 2023, Mark was elected to the board of Open Digital Cooperative, the body that oversees the LocalGov Drupal project. He is joined by:
 

  • Will Callaghan, Friendly Digital
  • Finn Lewis, Open Code
  • Maria Young, Agile Collective
  • Kate Hurr, Cumberland Council
  • Michael Brown, Newcastle Council
  • Jamie Dixon, Wirral Council
Oct 12 2023
Oct 12

5. How we delivered a language learning website to rural internet-less schools in South Africa using Drupal 

Why this session? 

DrupalCon is pretty much about connectivity and technology, yet here we have this presentation about creating a website that will not be online, for a group of people who do not own devices that will allow them to use the internet, and they are barely literate. Where do you even start finding solutions to the ultimate accessibility challenge? 

I am South African, and have lived in this country which has one of the world’s biggest gaps between the haves and the have-nots, for many years. This mega gap is a very hard thing to witness. But there are people doing incredible work, solving problems that a few years ago would have seemed impossible. 

When is it? 

Thursday, October 19, 2023 – 10:30 to 11:15 

What is it? 

In South Africa, 78% of children who are nine and 10 years old cannot read for meaning in English. That's because, in this particular school year, they're required to switch from learning in their home language (South Africa has 11 official languages) to learning in English. 

Read to Learn is a project imagined by the people at Oxford University Press, and presenter Dane Rossenrode is the web designer and web developer on the project

Using innovative "offline server" boxes and Drupal, what they’ve created is a highly interactive website where children can go through lessons, take quizzes, and play interactive games. And they’re deploying them to schools in rural areas that don't have any internet connection! 

The schools have government-provided computer rooms or low-end Android tablets, which means that the entire system was built to work offline. Once a week, the box turns on its (weak) 3G radio to send simple reports back to the Oxford University Press team to analyse. 

Apr 06 2023
Apr 06

What is the difference between Drupal 7 and Drupal 10?

The biggest difference is that Drupal 10 has “backward compatibility”. Drupal 7 does not have this. In other words, Drupal 10 is able to use modules, customisations and data originally created for Drupal 8, with some minor alterations.

Because deprecated code needs to be deleted, Drupal 10’s code is clean, the platform itself is nimble and this results in excellent website performance.

Drupal 10 is user friendly, easy-to-use, versatile and scalable. Some more technical differences include a new theme engine called Twig (introduced in Drupal 8), which replaces PHPTemplate in Drupal 7.

Because Drupal 10 requires an up-to-date hosting environment with the most recent PHP database engine or key-value store, it is faster than Drupal 7.

Content modelling has been simplified, so Drupal 10 is great for content-heavy web applications. CKEditor, a new text editor, provides users with many WYSIWYG editing features that were previously only available through extensions.

CKEditor 5 is available in Drupal 10, and looks amazing! Other features are responsive images, improved multilingual capabilities, JSON:API and more modules out-of-the-box.

Mar 07 2023
Mar 07

6. Links are hard

Particularly links with numeric IDs.

Links can point anywhere, so everything we just said about dependencies goes out of the window! Unfortunately node IDs have a habit of appearing publicly even if we try not to. Then they become a leaky abstraction.

We tend to run all our HTML text fields through a process plugin and try to clean up as much as possible. Sometimes we can establish if there’s an alias in D7 and use that.

The worst scenario is if you are migrating content with numeric links, and you combine migrated and new content. We’ve started experimenting with reserving a block of IDs for legacy content, like this:

  ALTER TABLE node AUTO_INCREMENT 100000;

We tried this on our most recent migration project, and it worked beautifully. It also helped during the UAT process, as there was never any question about whether we were looking at the same item of content on the legacy and migrated sites.

Mar 07 2023
Mar 07

3. Derivatives

Scaling your configurations can be made simple by using derivatives.

When you have a large number of migrations, with varying variations and discrepancies between sites that have slowly diverged over time, what you may need to do is define a base configuration to cover the commonalities, and then create a separate migration file for each variation which extends it. This allows you to run each of the individual migrations covering all the variations, but as the project scales and the number of variations increases, so does the number of YAML files – it can all get quite tricky to manage! This is where derivatives are extremely useful.

Derivatives provide a simple way to expand a single plugin so that it can represent itself as multiple plugins, and are used in other parts of Drupal, not just in migrations. To implement derivatives, you just need to add in an extra line in your YAML file to define the path to the deriver plugin you want to use. This causes your YAML file to become a definition of a base plugin and then it’s up to the deriver to take this base definition and generate lots of copies.

The end result is that we end up with lots of migrations that operate and behave the same as normal non-derivative migrations, but rather than multiple YAML files to maintain covering all of these migrations, there is just one base YAML file.

This is a huge time saver when it comes to creating, or later tweaking the migrations. You can just edit the variations in one central location, and avoid having to edit multiple YAML files when you need to change something later.

The derived migration machine names are a bit different from what you may be used to. They take the format of the base identifier, colon and derivative name (base_identifier:derivative_name). For example, if you have a migration for the “page” content type and create a derivative for each site in a multisite, then the derived migrations could have names like “node_page:site1”, “node_page:site2” and so on.

Similarly a set of derived taxonomy migrations could be created as “taxonomy_term:tags”, “taxonomy_term:product_types”, etc. Other than this slightly different naming structure they are exactly the same. This article has the essence of how to actually use derivers: “Migrations can now be derived and executed after a specific other migration.”

Dec 06 2022
Dec 06

Theming

Our frontend developers are very excited about improvements to the theming system. A new admin theme has our Director of Development Mark Conroy rubbing his hands together in glee.

The "Seven" theme will be removed and Claro will be put in its place, which is a much more elegant theme to work with and has had lots of accessibility testing on it. 

Claro is the admin theme that was adopted from Drupal 9, and it offers a better administrator experience.

Second on Mark’s list is a new theme generator that will allow developers to change the markup of the base theme without breaking backwards compatibility.

“Up to now, any theme in Drupal core (such as Classy) could not change its HTML structure during the lifecycle of that version of Drupal. So Classy in D8 was the almost the same for the whole of D8 – five years – because if we changed it, then themes relying on it might break,” he says.

“In Drupal 10, we have a theme generator – Starterkit – that will create a brand new theme for you each time you want it, rather than relying on a base theme. This means we can improve and change the HTML as much as we want, since your base theme will always be the latest version.”

Twig

Template engine Twig was introduced into Drupal more than seven years ago, and since then Drupal’s front-end developer experience has remained stagnant. But that’s about to change with new Twig features such as new filters to potentially save time on writing custom functions.

In particular, the |value filter in Twig is getting a lot of enthusiasm from developer Bill Seremetis.

“Now we get to use |value where we need it,” says Bill.

Frontend specialist Tony Barker is looking forward to various new features, in particular the dramatic improvements to built-in theme debugging tools (this is a huge leap forward from using third-party tools for advanced debugging).

Then there are improvements to loading CSS and Javascript, and replacing some JQuery components with modern JavaScript for performance improvements.

“Ending support for older technologies means new and improved features and sorting long standing problems and weirdness, an example of which is finally getting responsive views grid in core,” he says.

“So lots for developers to get excited about, maybe not so much in the way of shiny new front-facing features. But these changes help us to deliver those shiny new and improved front-facing things,” says Tony.

Other new features include Drupal's default front-end theme – its look and feel – Olivero.

It’s named after Rachel Olivero, who was head of the organisational technology group at the National Federation of the Blind, and is testament to the work she did around accessibility.

It is the most accessible theme that Drupal has ever been shipped with. Symfony 6 (comes standard and replaces Symfony 4) and PHP 8.1, both of which are required to keep the system secure.

Oct 10 2022
Oct 10

This is always pencilled into Annertechies' diaries. We love Drupal, and contributing to Drupal, and hanging out with others who are doing the same.

And sometimes, the solution isn’t what you want it to be – for example this Umami issue that was raised years ago, and which Adrien Sirjacques was keen to work on. The idea was to convert the demo content for Unami from CSV to JSON and demo JSON:API at the same time. Unfortunately, after some work, it was decided this change wasn’t a particularly effective use of Drupal's JSON:API capabilities. But still at least there was some closure after a few years.

Bill Seremetis and Tony Barker dealt with an issue to simplify the field markup, an idea originally proposed by our Director of Development Mark Conroy. Unfortunately this opened a can of worms because it affects many areas of core so there will be a fair amount of work ahead.

Bill also wrote and prepared the area for the official documentation for the project browser module which was such a hot topic throughout the conference (and in the process he got the chance to meet Chris Wells with whom he co-maintains the dgo.to and dgo.re sites).

There was a buzz around front-end tasks for Drupal 10 readiness, documenting changes to theming coming in Drupal 10 and solving some problems with the automated tests. There were so many people collaborating on this that the tables had to be reorganised.

Aug 11 2022
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 15 2022
Jul 15

Hosting websites can be unnecessarily hard. Websites themselves are already complex. And global traffic can mean huge numbers with big spikes in activity, so sites need to be served quickly, consistently and reliably.

Downtime costs money, effort, and more than likely a few extra grey hairs too.

Hosting providers 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 about 20 security updates 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.

Apr 26 2022
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.

Apr 03 2022
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.'
with
'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 an 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.

Jan 18 2022
Jan 18

Annertech and Drupal – They are synonymous. The Annertech team has been working on and with Drupal since the agency started in 2008, and is regarded as one of Europe’s most experienced Drupal specialist agencies. 

And what better way to affirm our commitment to this amazing open-source project than to become a signature supporting partner of the Drupal Association.

“We have always believed in giving back to the Drupal community and are delighted to be able to support the Drupal Association in this way,” said Stella Power, who is the managing director of Annertech and a well-known Drupal contributor.

The Drupal Association is the non-profit organisation that supports the Drupal project, its community and its growth. Not only does it organise the annual DrupalCon events, it is also responsible for some of the most critical elements that sustain Drupal as a software product, including infrastructure, updates, security advisories, and localisations.

We are committed to the association’s goal of advancing the Drupal software and growing its community.  We are therefore delighted to be able to support the association’s programmes by becoming a Signature Supporting Partner, up from the previous level of Premium Supporting Partner. 

Nov 25 2021
Nov 25

Advantages of decoupled websites

1. They’re secure

When we create a decoupled website the storage of the data and the servers are in one place and the actual website is somewhere else. For example, my personal website is hosted on Github Pages but the CMS is behind a firewall, somewhere where nobody else can get to it. There’s no database, no server, and no forms that might make it hackable. And that right there is a very enticing proposition for local councils: to have a very secure website.

Another benefit of this can be seen when it comes to updates. For example, when there is a security update for Drupal there is a rush to get applied (because it is open source anyone can see the source code at all times).

When it comes to a decoupled site, since the Drupal backend is stored off-site and locked away and not available on the open internet you can take your time about doing your updates. The updates definitely need to be applied, but the urgency is removed.

2. They’re fast

Aside from the security, there’s the idea of speed. Performance is one of Google’s metrics for search engine ranking, and one of Google's core web vitals metrics is the user's experience when loading a webpage.

These metrics include how quickly a page loads, how quickly a browser can respond to a user's input, and how unstable the content is as it loads in the browser. As an SEO metric, having a fast website is as important as having good content.

Decoupled sites are fast because they do not interact with the database and do not gather all the parts of a page before putting the page together for you. Rather, they deliver the whole page, fully-formed, in one go.

3. Scalable solution for microsites and campaign sites

Decoupled sites are a good choice for local governments because many councils have a large number of websites. For example, in addition to a main council website there might be numerous small microsites for events such as a Christmas campaign, a local food fair or a St Patrick's Day festival.

Each microsite has its own hosting platform, database and developers who maintain it. The costs start to snowball when it comes to this many sites. If there’s a security update for a CMS then multiple different websites need to be updated and tested – and when it comes to a council website there could be 30 or 40 different websites that need to be updated.

Within a decoupled situation, we'd suggest just one CMS – so when there's an update, only one platform needs to be updated; when there's a new feature request, it needs to be applied to only one site.

This simplifies things beautifully. Decoupling would mean that all the council’s content could be stored in one place, so content editors just need to get used to use one system. They could, for example, create the news for all the different websites on one website and then tag that news as, say "Christmas" or "food festival". After that, the decoupling system will pull those content items into the individual websites.

The situation can be tailored to specific needs. The main council website could be decoupled – lighting fast, un-hackable and future-proofed. And then additional microsites could be added as they’re needed.

Microsites can retain the branding of the main site or they can have a completely independent look and feel. But the idea is that all content is stored and managed in one place.

It should homogenise your content and make it much easier to keep track of it. So as we've said, it means content designers and editors only need to learn one system, and if they want to update any system – a website, an app, a microsite, etc – they just have to log in to the one shared CMS.

4. Costs and time

Many councils prefer to pay for one website rather than for 50 websites. A decoupled site allows for this.

For example, when working with the Irish Centre for High-End Computing we created a system in which all microsites are created in the current Drupal CMS, but not displayed there. To create a microsite, it's a matter of simply tagging each post or page with the name of that microsite. There can be as many microsites as needed, either following a set design or with a custom design.

If ICHEC wants a new microsite for, say, Science Week 2022 and Science Week 2023 and so on, this can happen with very little development time. We’ve built a system where the content creators can create all the news posts and the home page by adding a category on the website called Science Week 2022 and tagging each page they want to appear in the microsite with this.

It will take us an hour or two to get the infrastructure set up for each website with the website live straightaway, rather than taking us a number of weeks to build a new website.

5. Redesigns and migrations

Redesigns and migrations are a double-edged sword. You have to do them, and things usually look and run better once they’re done. But they take time and cost money.

When it comes to a decoupled site, because the backend and frontend are decoupled from each other either of them can be updated at leisure without affecting the other part.

So let’s say someone wants move their website from Wordpress to Drupal. They can afford a new look for the website but can’t afford to update the whole database and migrate all the content to a new system.

We can redo the decoupled frontend – and it would look brilliant – and then in a year’s time when they have the budget to update the backend we can get on the backend and the frontend remains the same. There can be different stages of development, so they can move at the pace they want.

Please see the video below that I presented at DrupalCon Amsterdam on GatsbyJS and decoupled websites.

Oct 20 2021
Oct 20

What are the benefits of LocalGov Drupal?

1. Low cost

With no licence fees to pay, and being free and open source, LocalGov Drupal means you can have a best-in-class, enterprise-grade website for your council at a fraction of the price of a licenced, proprietary website. And remember, you’ll pay that licence before a line of code is written to develop the website to your brand guidelines. Meaning, with LocalGov Drupal, budget is freed up to spend on other services for the homeless, health, education, etc.

2. Rigorously tested

Since LocalGov Drupal is a collaboration between a number of councils and development agencies, it’s well-tested before any new feature is released. More, you have the reassurance of knowing that each feature has an automated test suite alongside it, developed by some of the best Drupal developers in the world.

As well as that, you can see for yourself websites built on the codebase – Brighton-Hove, Cumbria, Bracknell Forest, Croydon, and many more. And being open source, you can have your in-house developers download it and validate the codebase.

3. WCAG 2.1 AA compliant

LocalGov Drupal is built with accessibility at the core. Each feature is tested from a number of accessibility standpoints and WCAG 2.1 AA criteria. We want to ensure everyone can use our websites fully, whether they have accessibility requirements or not.

4. Faster development time

As the features you need for your council website are already built and ready to go, development turnaround time is much faster. Typically, creating a new council website can often take up to a year. However, LocalGov Drupal websites are typically launched in only 8 to 12 weeks.

And, with a shared feature set, the development budget is mostly used creating the look and feel of your website (called “frontend development” – fonts, colours, spacing, etc). Given Annertech were tasked with writing the base frontend system for the platform, who better to implement it on your council website.

5. No vendor lock-in

As an open-source product, there is no vendor lock-in with LocalGov Drupal. You do not need to sign up for a licence for any period of time. If you want to take your website and have another development agency work on it, you are free to do so. You own the codebase at all times. All you’ll need is another Drupal specialist.

6. Share features

Collaborating with others means we learn from one another. Through LocalGov Drupal you have access to people who have solved a problem you’re currently experiencing.  

What if you want a feature that isn’t available yet? Simply send a proposal to the product working group. If your proposal is accepted (i.e., it’s a feature lots of councils will use), we will work on it. If it is not accepted (perhaps it’s very specific to your council), you are free to work on it yourself and maintain it for just your website. Also, you could  share it with the smaller number of councils that will need that feature.

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.

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.

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.

Dec 12 2019
Dec 12

Maybe it is your first website. Maybe you've been here before, but you're starting afresh. You're full of enthusiasm. In your dreams, your website looks like a flashy cruise liner - huge, and with every amenity money can buy. However, your budget stretches to a dinghy with an outboard motor. So how can you rationalise your aspirations within your financial constraints?

You don't have to be a paragon of fiscal rectitude, but you do need to prioritise, and think a little cleverly about how you can approach the project.

Lego boats

Taking the boat analogy a little further, both the cruise ship and the dinghy can arguably meet your needs. Both will keep you out of the water. Both will get you from A to B. Both have the potential for memorable holidays. Sure, the cruise ship has a roof, but you could elect not to go boating in the rain, so the question is: do you need a roof?

Making your website fit your budget is all about prioritisation, and the realisation that not every available feature is actually necessary, or often even a good idea.

Time, cost and quality. These three things go into your project. You don't want to compromise on quality, because that will cause you problems in the future. You don't want to rush it too much because that will lead to mistakes. Your budget is limited, so the only thing that can be a variable is the scope of the project.

An On-going Development Relationship

This is where things get interesting. A website is not just for launch day: it is for the duration of its life. And over that lifetime, we would expect it to see new content, new features, new sections, upgrades, design changes... Users expect to see change when they return to your site, and this empowers you, the site-owner, to embrace the process of change over a longer time. Rather than trying to build a huge monolithic project on day one, why not stagger your build over a longer time, and use it to bring new features to your users as they are ready?

Take, for example, a house. When you buy a house, it is generally considered a poor idea to immediately demolish part of it and build extensions. It takes time to digest, time to experiment, time to learn what elements you like and which you really can't live with. Equally, you need to learn how your needs have changed in your new house and how they are different to your imagined needs before moving in. You'll also want to think about how your house works within its environment - where does the sun come in? are there any problematic times of year?

So too with websites. Just as you'll figure out your needs over time, it pays to keep an eye on what is happening and changing in your industry and the internet at large since you decided to invest in a site.

Start Small, Extend and Prioritize

So, with websites. As you start to use your site you will have ideas and wants and needs. If you have started small, with a view to extending your site, these ideas can be embraced and your site will grow with you as your experience and that of your users illustrates what the needs really are. Change can now be embraced, nurtured and turned into features that both you and your users really love.

The irony is, that in most traditional projects, everyone is asked to do most of the planning, thinking and budgeting at the very outset - which is the point where everyone concerned has the least knowledge about the project, its constraints (both known and hidden) and its goals. This is essentially gambling and is fraught with the danger of failure.

Project knowledge increases over time

An Example Timeline

To illustrate a staged approach to development, here's a timeline for a simple web project.

Day One - Install Drupal and build our first content type: the basic page. We've identified half a dozen pages of content that will describe who we are and what we do. We'll include a FAQ page to releive pressure from staff and some downloadable documents to reduce printing costs. We'll also install Webform to get a contact form on the site. We'll use the core menu system for navigation. We get metatags and Google Analytics to keep on top of our SEO. We'll set up a solid, responsive theme, but will intentionally keep the design very simple so that we can embellish it later. 

Pre-launch - We set up the site on a specialist, tuned, managed Drupal hosting platform and are ready to go.

Launch Day - We go live with a great looking, dependable, flexible, and fast, responsive site. The site is saving us time and money, increasing our visibility and working for us - from the start.

Two months in - We decide that we want a blog, in order to entice visitors and to establish ourselves as thought leaders in our industry. So we add a content type and a views listing (blog listing landing page), and some additional design and styling to make the blog articles look pretty.

Four months in - The blog is going well and we're getting readership traction. We would like to get further traction and extend our reach into social media. We build in share and follow buttons and Twitter cards to drive traffic. We add a block of latest blog articles to the home page.

Six months in - We decide to integrate Mailchimp to let people sign up to our new newsletter, in order to increase our reach and better communicate with our prospective customers. We get a newsletter signup block on the home page and all blog pages. We add some more design flair to our blocks to make them really sing.

Eight months in - We decide to open up a dialog with our readers, adding comments, and of course, spam protection!

Twelve months in -  We launch a range of beautiful products sold through a fully featured, integrated e-commerce solution from our site.

Who knows where we'll go next?

This is an example, but it could be your project. By starting with the bare minimum and extending the site over time, the site owners and developers have full knowledge of the project at all times and importantly, full knowledge of what they like and don't like. Each item of functionality is discrete and self-contained, allowing proper testing and proper scheduling of deployments.

The benefits of such an approach include:

  • Spread the cost of your site build over a longer time for less financial impact
  • Smaller chunks of work allow for defined, short-term goals and milestones
  • Each new feature is the most important feature to the site-owners, right now, so they get what they want quickly
  • Users enjoy a fresh site with each visit
  • The site can react to changing business needs
  • The entire team builds up project knowledge with every new feature, reducing potential for problems and on-boarding overhead, which all means a more efficient build process
  • Better bang for your buck because only the most important items are built and only these items are styled. You never end up styling something that is never used, and equally, you never end up with an un-styled feature because you ran out of budget.

Consider this approach if you:

  • are getting your first site built
  • have limited budget, but grand aspirations
  • are rebuilding your site from the ground up
  • don't have a lot of time to spend writing lots of content or answering endless questions from your developers
  • think your requirements may change, or are at all unsure what they are

When you're ready, we're ready.

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.

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 designer, 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.

Conclusion

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.

Oct 06 2017
Oct 06

We were also privileged and honoured to have the opportunity to present five sessions ourselves, and of course, we once again played host to the Drupal Trivia Night. There was a lot going on, and it was a fantastic week, but here are just some of the key moments I experienced during the week.

Monday Summits

For me DrupalCon Vienna started with the Business Summit on the Monday. I had great difficulties in deciding whether to attend the Community Summit and the Business Summit, and while I still think I missed out on some very interesting discussions that happened at the Community Summit, the Business Summit still didn't disappoint. There we had great sessions and discussions on topics such as marketing and collaboration. In the afternoon workshop, we split out into groups based on our organisation size, which proved much more useful than past summits where the groups were based around topics.

Tuesday

Alan with his new Acquia Developer Certification

Unfortunately I didn't make it to the prenote on the Tuesday morning, but really enjoyed Dries' keynote, where he re-affirmed something I had already come around to believe - that Drupal is not for simple sites, but instead for sites or digital experiences that require a certain level of customisation or flexibility.

Mike had his session after the keynote on "Estimates are dead, long live forecasting!" which went well, though I was disappointed to have missed the start of it as I was too busy chatting to people! My session on "Lessons Learned from Building a Large Multilingual, Multi-region Site in Drupal 8" was in the afternoon, for which I had a full room and there was a good level of interest and good conversations afterwards. With my session out of the way, I was able to focus on enjoying the rest of the conference a lot more - oh yes, and finishing the trivia questions too!

On Tuesday night, we had a number of different things to celebrate, but one of them included Alan gaining his Acquia Developer Certification. Congrats Alan! 

Wednesday

Two more Annertechies were speaking on Wednesday, Andrew on "Core Accessibility: How are we doing, and what can we do better?" and Mark on "Back to the Future: No More Static Mockups!". Unfortunately I missed Mark's session as I was taking part in various meetings and BOFs on deciding the process for licensing DrupalCon Europe in 2019, and also what could be done to organise a major Drupal Europe 2018 event.

For me, Wednesday wrapped up with the annual Drupal CEO dinner, with great food and great conversation with a diverse group of people from Europe, the US and further afield. It really was a great evening, and I would have liked to have stayed longer but those trivia questions weren't going to write themselves!

Thursday

Thursday saw the last Annertech session given by Anthony on "Live Performance Workshop: A top-to-bottom performance overhaul", which for those of you who missed it, will also be at the upcoming Drupal Camp Dublin on the 20th and 21st October. I also took part in the Drupal marketing sprint, which saw people come together to create tangible marketing collatoral by the end of the four hour session. One of the key outcomes of it was the initial mapping of a Drupal buyer's journey, and the start of a blog post / showcase of publishing websites built with Drupal. It was a great initiative and one I hope will continue on.

Anthony speaking at DrupalCon ViennaAnthony speaking at DrupalCon Vienna, photo credit to Dominik Kiss

Of course, no DrupalCon would be complete without the (now) traditional Trivia night. It was a really fun way to wrap up the conference, and yes, I did get the questions finished in time! However, organising trivia night is a lot of work, so if anyone out there wants to get involved and help me write the questions for each trivia night, please do get in touch!

Crowd gathered for Trivia night at DrupalCon ViennaPhoto credit to Dominik Kiss

Highlights from the team

However, I wasn't the only Annertechie to make it to DrupalCon, so I asked the team to give me their top highlights from the conference, and here's what they said:

Mike

"There’s still something really useful about having the whole team at the same conference as well as having the ability to hop across session boundaries and see something you wouldn’t go to a topic-specific conference for".

Anthony

"Comment _why_, not what. That was my key take-away from the conference, thanks to a session by Commerce Guys. When documenting a function in code, the `what` of a function may change, making the comment outdated, but the `why` or the problem the function is fixing will most likely remain, and that is what should be documented."

Andrew

"There was a great birds-of-a-feather session about redesigning Drupal's admin interface.  It was great to have so many stakeholders together to talk about the scope of this idea, and it felt like a kick-off meeting for something ambitious. It was the first time I've been present at the start of a big project inside Drupal core, and it's going to be interesting to see how this gets refined into a plan."

Mark

"It’s humbling to experience the amount of knowledge that is floating around the convention centre, being freely shared to solve some very complex issues. From my point of view, it was great to get direct access to core committers and maintainers about some issues that might arise during our development of the Out of the Box initiative."

Alan

"If you want to improve as a developer you need to see what the best in the field are up to.  Reading blog posts will only get you so far - there’s no substitute for meeting the experts in the flesh and picking their brain"

Ricardo

"From a designer point of view the `CSS-in-JS: unexpected lessons for Drupal component design` session was my favourite session, with the highlight being the confirmation of what I already believed - that component based design is the way to go."

Gavin

"For me, the session on "Automatic Drupal Updates using Visual Regression & Continuous Integration" was fantastic, with my key takeaway being how to use automation to add value for your clients."

To wrap up - we all learned too much, met too many great people, had too little sleep, and are looking forward to doing it all over again at Drupal Europe 2018 - wherever that may be. Thank you DrupalCon Vienna!

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:

Sep 14 2017
Sep 14
Then say your client says something like "This is great, but all the related content looks like the teaser on the listing page. Can't we choose ourselves how we want it to look?" What's your response? You say yes, and you go install Display Suite or Panels or some other heavy duty module? Or, say yes and follow these neat little instructions. No one says no to clients, do they?

Here's what you need to do:

1) Install Twig Tweak

Twig Tweak is such a great module you should have it on every website. Don't believe me? Read what I did with it to allow editors to choose the image style they wanted for their images.

2) Add a Node Reference Field

Add a field to your content type (or paragraph type, etc) that allows you to reference content. In my case, I called it 'Related Content', with a field name of 'field_related_content'. On the manage display page, you can leave this field as 'Disabled'. We'll load it using Twig Tweak in a minute.

Drupal Entity Reference Field in Disabled Region

3) Add a Select List Field for the View Modes

Add a field of type 'Text: List'. Set the keys of the options of that field to be the same as the machine name of your view modes, like so:

teaser|Teaser
full|Full
title|Title
 

Make sure editors can only choose 1 value, and set a default value just in case they forget or neglect to fill in that field.

Select view mode for related content

4) Render the Referenced Content, using the Chosen View Mode, in your Template

Once you are that far, use code like this to render the selected related content with the chosen view mode:

{% if node.field_related_content.value %}
    {% set custom_view_mode = node.field_view_mode.value %}
    {% set node_id = node.field_related_content.value.0.target_id %}
    {{ drupal_entity('node', node_id , custom_view_mode) }}
  {% endif %}

Here's the notes on what is going on:

First, make sure the 'Related Content' field is filled in, or else we'll be rendering empty divs.
{% if node.field_related_content.value %}

Next, set the value of the select list as a new variable called 'custom_view_mode'. 'view_mode' is already taken in the node.html.twig template.
{% set custom_view_mode = node.field_view_mode.value %}

Then, set the ID of the referenced content to a new variable called 'node_id'
{% set node_id = node.field_related_content.value.0.target_id %}

Finally, use Twig Tweak module to render the entity of type 'node' that has an id equal to our 'node_id' variable , and render this node using the view mode that is equal to our 'custom_view_mode' variable.
{{ drupal_entity('node', node_id , custom_view_mode) }}

So there you have it - render an entity using a view mode in a template in just 5 lines of code.

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!

Mar 29 2017
Mar 29

Hang on, doesn't that mean that the age old problem of people's heads getting chopped off will rear it ugly head (excuse the pun)? In the olden days, yes; but given the AMAZING work the Drupal Media team has done, we were able to use a cropping tool (Image Widget Crop) to allow editors to choose how each image would look for each image style created. This means one image uploaded to the site, reused in many representations, without fault. How we did that can be explained in another blog post - for now, these screenshots should suffice to show how seamless our solution works:

Drupal 8 media crop - landscapeDrupal 8 media crop - portrait

And now for our solution to allow editors to choose which version of the image they wanted for teasers. What we did was created another text field with two options 'Landscape' and 'Portrait'.

Drupal 8 node edit form teaser section

Then in the twig file for the teaser view mode (node--teaser.html.twig) we checked what the value of this field was. We then used the 'Twig Tweaks' module to load the image with the corresponding image style.

The code looks like this:

This blog post was inspired by Third & Grove's blog post - One Image Field, Multiple Aspect Ratios.

Jan 09 2017
Jan 09

One of the ones that seems fairly stable and has a good set of features without being overly complex is the Geolocation Field module. We've used it on a site recently with great success, and in this blog post we will cover the fundamentals of how to use this module.

Add a Geolocation Field to your Content

After enabling the module, the first step you need to do is add a geolocation field to the entity you want to associate a location with. Locations are stored as latitude and longitude value pairs on the entity. This can be any entity type, but for the purposes of this we chose to create a Location content type and add a geolocation field to that.

The default configuration for new geolocation fields is to provide latitude and longitude text boxes on the node edit form. This may be suitable for some sites, but we needed the ability for the user to enter in an address which is then geocoded, and to be able to adjust the pin location if the calculated co-ordinates were incorrect (as is often the case with Irish addresses).

Luckily, the geolocation field module provides this functionality out of the box. On the "manage form display" page in the entity configuration, you can choose the type of input widget the editors will use. The "Geolocation Google Geocoder" is the option you need. You may want to configure your Google Maps API key at admin/config/services/geolocation if using this option however.

Geolocation field - manage form display settings

Similarly, the module also provides a number of options to choose from on the "manage display" page. In our case we chose to display the location on a Google map, rather than outputting the latitude and longitude values.

Geolocation field - manage display settings

After selecting the "Geolocation Google Map" display output, you can then customise its display. For example, you can choose between a Road Map view and Satellite Map view, set the map zoom level, disable/enable various map controls and dimensions.

You can now create your Location content and associate a latitude and longitude with each. Below is a screenshot of what the edit form can look like. Here we have manually entered in an address and the Google geocoder has calculated the latitude and longitude from that. Note, it's not possible to drag and drop the pin to a different location (which caught me out a few times), instead clicking anywhere else on the map will move the marker there.

Geolocation Google Geocoder widget

Create a View

After adding all of our mapped locations, we needed the ability to display them all on one Google Map view. To do this we created a new view of our content, and in the view format settings, we choose "Geolocation - Common Map". In order for this view format to work, you will need to add the geolocation field latitude and longitude co-ordinates to the view and a title for each location (which will appear in the popup). You can also optionally add an image field (make sure to choose the file uri output here) to the view which will be used as a marker for each location. This allows you to customise the marker per node.

Geolocation views format settings

Similar to the manage display settings on the node, you can also configure the map controls, zoom level, and so on. One other setting worthy of mention is the "JSON styles" setting. This allows you to embed a JSON encoded styles array to customise the look and feel of the rendered map. This is incredibly powerful and allows you to have a custom Google Map style that matches the design and colour palette of your site. Styled Google maps are easy to define using services such as Snazzy Maps.

The Results

Not everything we needed was quite there so we contributed a number of patches back to the module to make this happen, all of which have now been added to the module, yay!

Using the Geolocation Field module, we were able to map all our Location nodes and produce a map as can be see at the top of this article. If you want to see it in action, visit Glanbia Nutritionals.

Other Modules

At the time of launch, the only other modules that were available were Styled Google Map and Simple Google Maps. However, neither of these supported all the features we needed. Since then, a beta version of the Leaflet module has also been released. Have you used any of these or other mapping modules in Drupal 8? We'd love to hear what you thought of them. Why not let us know by leaving a comment below?

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.

Pages

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