Automate Illustrator for name badges & lanyards

If you ever needed to set up variables in Illustrator (like me), you may have been in a situation when just 10 minutes into the task you wanted to throw the Mac out the window.

I have no idea, if this simple guide will work in other versions of Illustrator, but I have used version 18.1.1.

There were a lot of tutorials available, although only after I combined them all, it worked! The biggest issue I faced was setting up the xml file correctly (and it’s not just simple xml either!). You need to use a special converter to create it correctly (and not just any xml converter!).

I will describe all of my steps, as maybe you are just like me – a newbie to Illustrator.


  1. You should have an Excel or CSV file to start with. I had a CSV with all the participants for the event (which I exported from Eventbrite).
  2. Select all the values (apart from the titles in the top row) and sort asc/desc in alphabetical order.

    Initial file

    Initial File

  3. It is vital to have the top row headings and make sure they don’t contain any spaces or special characters. These will become you variable names later on (make them simple and short).
  4. Create a new column on the left. This is also very important. Name it Dataset and you can copy all the values from the first column to it (or put in numbers if you’d like). Data in the first column must be unique, so make sure to go through all the records and amend them. If you’re using Excel:
    1. create blank column on the left,
    2. name it Dataset,
    3. put in number 1 in the first row
    4. drag down the first cell to create unique numbers.

      I changed First Name to FirstName, added new column with copied names and called it Dataset

      I changed First Name to FirstName, added new column with copied names and called it Dataset

  5. If using existing values make sure they don’t contain spaces or special characters – those will become variables too.
  6. Make sure there aren’t any “funny” characters in the file (like á etc).
  7. Save (or export as CSV). You can open it in text editor (i.e. notepad or Sublime) and make sure none of the lines end with a comma and none of the variables have spaces etc.

Convert to XML

  1. Open the CSV in a text editor and copy all (delete last line if it’s blank).
  2. Open this site
    That's my XML file structure after conversion..

    That’s my XML file structure after conversion. As you can see, it has some Abode references.

    and paste the contents of the CSV there. Copy the results and create a new file and save it as an XML. It’s important to use this converter as not all converters create AI compatible code. Or use an alternative if you like risk 🙂



  1. Open Illustrator and create a blank IA file.
  2. Open up variables (Window -> Variables). Add some text to the file. Highlight it and then click Make Text Dynamic at the bottom of Variables.

    And click the make the text dynamic

    Click the make the text dynamic. This assigns the variable to the text.

  3. Repeat as many times you need. I.e. if you have FirstName, Surname, TicketType, create 3 variables, each assigned to some text. Their names must match to those column names from your XML.


    Then click on that top right icon there, select Load Variable Library and locate it on the disk.

  4. Yes – override 🙂 Yes!
  5. If you set up your variable names correctly, your variables will populate then. Select a dataset from the dropdown to preview.

    Preview datasets

    Preview datasets

  6. You’re ready to export your files!


I never used batch processing in Illustrator before (or even Illustrator!), but it was very easy to set this up.

  1. Open up Window -> Actions. Create a name and hit Record.

    Record actions!

    Record actions!

  2. Go to File -> Export -> Select PNG extension and give it a name. Click ok and stop recording.

    Finish the action

    Stop recodring

  3. Click on the top right icon in Actions. Select Batch from the list.

    Select Batch

    Select Batch

  4. Make sure that correct Action is selected on the list, the source is set to DataSets and towards the bottom.
  5. Destination should be None, but click “Choose…” to choose where to save the new images. And tick Override Action “Export” Commands. Select File Name: as Data Set Name (or File + Data Set Name). And click OK.
  6. …and watch the magic happens!
  7. Check the destination folder. The files should start appearing there 🙂

Now – if you managed to go through all those steps and produce your name badges (and not go mad) – you deserve a a break! I definitely need one!

Plus some links to some great people whose tutorials helped me! Kemie Guaida and “Converting XML variables for illustrator“, Cheryl Graham “Quick Tip: Data Driven Graphics Using Illustrator’s Variables Panel” and “How to use Adobe Illustrator variable data with XML“. And, of course, the life-(and sanity)-saving CSV-AiXML Converter by Joao Faraco.

Website adaptation (part 1)

Gupta and Hilal (2011) describe website adaptation as the process of analysis of the device characteristics and then transforming the website based on those characteristics. It can be as simple as changing the navigation and enlarging the links for the mobile devices (Marcotte, 2010), although more advanced techniques are widely used, such as device-specific websites or responsive website design.

Adaptation is used to resolve the issues related to scrolling and the speed and size of the mobile websites. To remedy these problems, two common approaches to adaptation exist: graceful degradation (Florins et al., 2006) and progressive enhancement (Wells and Draganova, 2007).

Progressive enhancement is a way of accommodating a wide range of devices, screen sizes and capabilities. It is about starting with the basic HTML markup that should work on the least capable devices. The website is then enhanced, for example with CSS styling, only applied to the more capable devices. The last step is to add extra functionality (such as JavaScript) to enhance the website for the most capable devices. The better the capabilities of the device, the more advanced functionality will be enabled (Wells and Draganova, 2007).

On the other hand, graceful degradation is a technique of providing the best experience to the most capable devices. The less advanced devices and browsers will obtain a degraded version of the website. Although this means they some of the users will get worse experience than others, it ensures that those with the most up-to-date hardware and software will always get the best of the website.

The main difference between these two is that, while progressive enhancement aims to provide the best possible experience to any device, graceful degradation aims for the most capable devices first and then degrades the experience for the less capable devices.


Issues on mobile devices

*Please, note some of the reference links might not be available to view for free as they may refer to paid journals.

To begin with, the main difference between desktop computers and mobile devices is their size. From the size come all the other differences: mobility, ease of use, performance, battery life and input device. Mobile devices have the advantage of being mobile, as people can use them almost anywhere to connect to the Internet. Unfortunately, mobility comes at a price. Mobile phones have a reduced battery life, lower performance and often no input device at all. They might be considered more difficult to use because of their small size.

Furthermore, mobile support for web browsing is still not as well developed as for desktop computers. Probably the main disadvantage is the speed with which they can render web content. Because the Internet connection and processing capabilities are low, websites need to accommodate these problems.

Websites generally do not scale to the screen size automatically or they do so but not gracefully. It means that those designed for desktops might not necessarily look good on mobiles. For example, the website may load zoomed out to display the 100% of the width, making the content illegible or the mobile browser may enlarge the website, making a part of it hidden on the small screen. This was described as a direct migration by Gupta and Hilal (2011).

On the other hand, the linear transformation was expressed as the content being constricted to a single column fitting on the small screen. This means that the website will look a lot better, as one column of content would fit nicely on the mobile screen. An example of the linear transformation can be a website adapted to the mobile screens through responsive website design.


Because of the direct migration, the user is very often forced to scroll horizontally as well as vertically (Albers and Kim, 2000, Kim and Lee, 2006, and Hwang et al., 2003). See figure below for an example. Horizontal scrolling might reduce the users’ ability to find the information on the website (Adipat et al., 2011).

Scrolling (from the left): vertical, horizontal and both at the same time (Adapted from: Nebeling et al., 2011).

Scrolling (from the left): vertical, horizontal and both at the same time (Adapted from: Nebeling et al., 2011).

Scrolling in general reduces usability of the website (Gardner, 2011), and Florins et al., 2006).  An even worse situation is when the users need to scroll as well as zoom in and out in order to see all of the content (Pastore, 2012).

An example of the issues related to scrolling has been depicted by Korpi (2012). The inline-scrollable elements are in nature scrollable in a horizontal way if the element is wider than the page. The users have to scroll vertically to the bottom of that element and then scroll within it horizontally, which may be unacceptable and troublesome for the users (just imagine that to read this article you had to scroll left and right and up and down all the time).

Furthermore, because of the small screen size, not all of the information is visible at once, reducing the user’s ability to find the information on the website. The user is not only unable to see all of the information within the screen at any given time, but also needs to scroll vertically in order to see it (Chen and Chiang, 2012).

Possible solutions

Churchill and Hedberg (2008) have researched the relevant literature and performed a user study, which confirms that scrolling should be minimised on mobile screens. They also suggested that the text should be kept short for mobile screens.

In addition, Churchill and Hedberg (2008) advise that the navigation should be placed at the top and key content put towards the top of the page. This approach should limit the need for the user to scroll in order to locate information.

Gardner (2011) describes how to reduce the scrolling, by constraining the height of the navigation on the mobile device. It is done by transferring the form and list elements into a dropdown and can be achieved with a few lines of code (see figure below).

Navigation list changed into a dropdown to reduce scrolling (From: Gardner, 2011).

Navigation list changed into a dropdown to reduce scrolling (From: Gardner, 2011).

As Sanchez and Goolsbee (2010) noted, more scrolling is often caused by increased font size and spacing between characters and lines. They found through their study that excessive scrolling reduces the ability to remember the information. Thus, it is a good idea to avoid large fonts and character and line spacing for mobile devices. Sanchez and Goolsbee (2010) also suggested providing an option for the user to change the size of the font.

There were many other solutions advised to remedy this problem, for example automatic page splitting (Kim and Lee, 2006). These other solutions will not be described here, although it may be worth to study them as well at a later time.

Capabilities and constraints of mobile devices

 The capabilities of mobile phones are relatively low compared to desktop devices, due to their screen size, processing power and memory capacity.  In addition, they have small storage, limited software and reduced bandwidth.

Gupta and Hilal (see Extraction of web content to adapt web pages for mobile devices) point out that even though mobile technologies have advanced in recent years, their capabilities are still not good enough to properly render complex web content. The network connections for mobiles are slower than those for desktops (see Making the mobile web faster by Matsudaira), mainly because they still need to connect via a different method. Desktops take full advantage of fast broadband speeds, often even fibre optic connections.

Furthermore, not all web users own a smartphone, capable of 3G or 4G network connections; instead some own a less capable feature phone, which can only access the Internet via slower GPRS or EDGE connections. Thus, connectivity on feature phones is reduced significantly when compared with smartphones and even more when compared with desktops.

Wi-fi logo

Some smartphones use broadband through Wi-Fi, but they can only do so when in proximity of an access point. The situation is improving though, with many companies offering free Wi-Fi at so-called hotspots. For instance, the o2 offers a mobile application, o2Wi-Fi which shows their hotspots on a local map. Furthermore, some places will soon offer fast 4G connections, at a price.

All of this comes down to the price the users pay to connect to the Internet. Because free Wi-Fi is not available everywhere, they may need to pay for the data usage on their phones. For some, it is included in their monthly allowance, for others, it means increased bills.

pound sign

Most of the mobiles available today have smaller capabilities compared to desktops. It is evident though, that they are improving. For example, a feature phone might not have much RAM and CPU power, but the latest smartphones like iPhone 5 or the new Samsung Galaxy S IV do have specifications comparable with those of laptops or notebooks. The latest mobile phones offer at least 1GB of RAM and at least a 1.5GHz dual core processor.

Battery life is also improving, though it is still poor in comparison with desktops, which use a constant power source. Mobile battery decreases a lot faster when the device connects to the Internet, therefore it is still a big problem for mobile Internet access.

Considering the limitations of mobile devices, it is vital to keep the size of a website as small as possible, to ensure it will be rendered as fast as possible. The maximum optimal total size recommended by the W3C for a mobile website is 20KB. While it sounds like very little, it might be a good idea to reduce the size to as close to 20KB as possible to achieve good loading times, as it means that more mobile users are likely to visit the website.

To display a website, device needs to download it first. As mentioned, the largest constraint associated with mobile Internet is the cost of the downloaded data. As a result, bigger websites are costlier to download. In addition, as the bandwidth is limited and connection may be diminished, larger websites download slower. In a recent survey, 50% of the users stated they would not stay on a website if it takes more than 10 seconds to load (see How loading time affects your bottom line by Work).

The time the users would wait for a website to load

The time the users would wait for a website to load, as described by Work.

Mobile Web or One Web

Mobile web development used to be simple. There was the mobile site for mobile devices and there was the desktop site for desktop devices. But it is not as easy to define what mobile is, anymore.

Well, my opinion is that a mobile device is, in fact, any device that can be used “on the go” (hence “mobile”). Therefore, mobile devices include mobile phones (feature and smart), tablets, netbooks, laptops, phablets… and the list goes on and on with new generations of products. And what the future will bring is that there will probably be even more types of devices.

Mobile and Desktop

Mobile and desktop devices

On the other hand, there is a question of web. What is web? It used to be pretty simple, as well. But nowadays web can be used and viewed in so many different ways and on a lot of different media. I think that, despite the diversity of devices, there is only ONE WEB and it should probably stay this way.

As many believe, Web should not be divided into desktop web and mobile web. Because if we do that, what would be next?  Tablet web?  iPhone web? Where does it end?

The variety of devices

The variety of devices is growing constantly

Well, maybe not everyone would agree with that. But the One Web concept does come from the World Wide Web Consortium (W3C), the people who define web standards.  Probably, it is safe to say that they define what Web means, even.

W3C recommends adaptation of web content to ensure the website is accessible on the whole range of devices, therefore adhering to the One Web vision. Consequently, the Web of Devices under the One Web vision is about providing web access anywhere, to any device and at any time (Web of Devices).

Pastore expressed responsive website design as a way of implementing the One Web vision in web design, because it makes the user experience consistent. In RWD, the content stays the same across devices, while the styling (CSS) of the content adapts the website to different devices and screen sizes via CSS3 Media Queries. Therefore, a responsive website is in fact, device independent.

Since web was defined by W3C as One Web, it is even more credible to say that it should not be divided into many “webs”. Such division would breach the device independence, as the content would not be usable despite the type or size of the device it is viewed on.

Just check out what .net writer Addy Osmani thinks on the One Web in his article: “Don’t write for devices, write for people. It is a nice comparison between what One Web stands for and the “opposing side” – the people who would rather choose native application development.

The variety of devices

The variety of devices

Although I personally believe in One Web, I do not think that it should be that web creators only consider one option. Yes, there is a need to create “one content” for all. But also there is a demand for native applications in certain situations. Of course, not every brand or development needs one, but it is certainly beneficial to consider that option as well.

Addy Osmani (mentioned above) seems to summarise it all: “The One Web: don’t write for devices, write for people”. And it goes well with what I have learned during my final year project at University: websites should be defined around users’ goals. Therefore, if they expect a native application, then why not create one? Of course one would not just create a standalone app; there would surely be a website, too. Even though we provide an app for mobile users and website for desktop users, there should be a way for mobile users being able to access that website in addition to the app.

In other words, if we leave those who do not expect a mobile application, and do not offer them a proper website, then we are probably missing out a lot of potential users.

Responsive website design

Kamila Mielczarek

1. Introduction

An increasing number of people use their smartphones or tablets to access the internet. The number of different devices used by each user to connect to the Internet also grows (Mintel, 2012). Therefore, it is vital for the designers and developers (website creators) to decide how the website would deal with the range of the screens and devices. It is very often a question of whether to create dedicated desktop and mobile versions or a unified, responsive website.

As website creators need to cater for a whole spectrum of screen sizes, it seems they have no choice but to recognise the differences between the traditional and the responsive website design (RWD) approaches. This essay will attempt to answer this question.

2. Description and definitions

There are many definitions of responsive website design. The device-agnostic responsive design means that the website’s layout and design responsively adapt to the size, platform (i.e. operating system) and orientation of the screen of the device (Knight, 2011). Responsive website is meant to recognise the size of the device it is viewed on and respond to it in order to provide the optimal viewing experience. It might be done through rearranging certain elements on the page, enlarging or decreasing images or fonts or even disabling some elements (Fox, 2012, and Gardner, 2011).

On the other hand, there is a traditional approach, which is about implementing device specific versions for each device. For instance there would be separate versions of the site for desktop and mobile screens. This approach is less flexible in use, but sometimes might be more appropriate (Fox, 2012, and Gardner, 2011).

3. The choice to make.

While a lot of people focus on the responsive website design and almost praise it based on its benefits (Joly, 2012), little work has shown the disadvantages or limitations of this approach. Although so many web creators are very excited with this relatively new concept (Chowdhary, 2012, and Frain, 2012), not all of them have actually adapted it successfully. In fact, the first and the most important question web creators should ask themselves is whether or not the responsive design is the appropriate solution for their needs.

3.1. Speed and performance issues.

As Podjarny (2012, p.102-103) argues, responsive website design can introduce some serious performance issues. By testing 347 responsive sites, he came to the following conclusion: “86% of the websites weighed roughly the same when loaded in the smallest window, compared to the largest one”. It indicates that, while the website on the desktop will be loaded relatively fast, mobile users might suffer in this aspect, as their devices are not capable of processing large files as fast. This seems like a big obstacle to the RWD concept.

3.1.1. The problems with flexible images

Flexible images are often used on responsive websites. The technique used CSS3 media queries to stretch or squeeze the images according to space available. Therefore, on a mobile screen the image would be resized to take less precious space.

As Podjarny argues (2012, p.102-103) when flexible images are applied, the large image files would still be downloaded on mobile devices. This meant that, as perfect as the concept might seem, it can actually break the user experience if not implemented correctly.

While this thinking seems logic, other sources (CSS-Tricks, 2012) mention remedies to that problem, such as using Foresight.js and HiSRC tools to test for the bandwidth before serving images and based on that, choosing the image size to display on the website.

It is also recommended (Kadlec, 2012) to selectively choose the image size to be loaded based on the screen size, which can be taken one step forward by compressing the images for different devices. The process could be also improved by using sprite images that combine many images into one and therefore reduce the size even more effectively (Gardner, 2011).

3.1.2. Complexity

While device-agnostic RWD approach seems like a lot of extra work for the web creators to make it right, it is still arguably a better solution to the problem (Marcotte, 2010). What is there to prove that the device-specific approach is easier to implement? By using RWD to build their sites, web creators no longer need to think about the whole variety of mobile and tablet and desktop devices. The design should work exactly the same on the iPhone as it would on Android devices with minor only differences in layout. In RWD, it is the size of the screen that determines the layout and content of the website (Gardner, 2011), but the content only needs to be written once.

Podjarny (2012) also mentions that hiding the elements with display:none CSS style does not mean that the code will not still be loaded. Why limit ourselves to using it? It can be better implemented by serving device specific CSS based on media queries. Media queries would determine the device’s screen size and orientation and serve a dedicated CSS or image files based on that (Frain, 2012, and Kadlec, 2012).

3.1.3. Misleading guidelines

There are articles that praise the RWD approaches for the ease of use and speed of implementation (Chowdhary, 2012). They mainly focus on the fact that the responsive website design focuses on the content, but they are overseeing the good practices in order to achieve good results, such as a site that would load fast on a mobile device (Gardner, 2011). What they see is just the pure concept and not its implications, mentioned above.

Web creators need to remember that those guidelines do not always paint the whole picture and they should look for a variety of sources, pointing out the positive as well as negative sides of the RWD and use their own expertise to judge whether or not the guidelines are appropriate in each case.

All this leads to a very important point of the responsive website design, which is “content is key” and “mobile first”.

3.2. Content is key

“Content first” is mentioned in almost every article about RWD. It means that the web creator needs to first determine the core content for the website. They need to determine what is crucial and start with just those key elements (Podjarny, 2012, and Frain, 2012). A very good example of the project that was really beneficial from this approach is the library project described by Fox (2012).

Once the web creators decided on the core content, they should gradually build on that and add more features and content as the screen size progresses (Podjarny, 2012, Frain, 2012, and Fox, 2012). This enables the users of the smallest devices, such as mobiles to access the main information of the website without slowing the devices down. On the other hand, the desktop user is enabled to see a much richer version of the website.

Because “content is key” rule usually means developing the website for the mobile devices first, it is often referred to as “mobile first”.

3.2.1. Implications

The “mobile first” is an opposite of the commonly used approach, which would first cater for the needs of the desktop users and then focus on satisfying the needs of the smaller device users. Therefore, it requires changing one’s way of thinking, as it contradicts the ways in which web design has been done in the past. This might cause delays in the project, as the web creators re-organise their thinking.

3.3. Functionality

Apart from the key content, it is very advisable to decide about the functionality of the website early (Fox, 2012, and Frain, 2012). Provided that the mobile, tablet and desktop versions will offer the same functionality, then RWD could be implemented.

On the other hand, the mobile version might offer some additional features, such as built in maps (Frain, 2012) or that the desktop version features might be incompatible with other devices (for example, Flash is not supported on iOS devices). It would not make much sense to implement RWD in this case, as it would mean that either the mobile version would not function properly or it could be a lot of work and resources to actually “hide” the feature from the unsupported devices.

Therefore, it may be argued that specific mobile versions might be best in certain circumstances. The traditional approach would be viable provided there are different requirements for a mobile than for a desktop version.

3.3.1. Experience

Is this thinking right? Based on experience (of the author) this statement is correct. It proved to be, on one of the maintained websites during work experience. The Flash tool was not working on an iPad tablet. Therefore, it was agreed that the incompatible part of the website should be hidden on tablet devices. This, unfortunately, did not serve its purpose well, as the content of the website has been updated on a monthly basis and the links to the tool were constantly changing place, causing it difficult to track and hide the tool. Furthermore, the content was updated by various people, making it even more difficult to track.

3.3.2. Solution

In the above case, a tablet specific version of the website might have been a better solution and improved the user experience. On the other hand, a responsive website would have been even more costly to maintain, as the design would need to be constantly reviewed on a monthly basis. The scope as well as the usage of the maintained website on tablet devices was relatively small compared to other websites maintained by the company, making it even less feasible to change. If the website’s traffic was higher or if it produced higher profits, it would have been wise to invest the time and resources into making it response to the device’s screen size.

On the contrary, if a website’s functionality did not differ across devices, it would be advisable to apply responsive design (Frain, 2012). This would mean that no matter which device the website was viewed on, it would always serve the most important principle of the RWD – the content is key. This aspect of responsive design gives the users the freedom of choice. And no matter what their chosen device would be, they will always access the most relevant content of a given website without worrying that they might miss something.

It would also remove the element of confusion – as the user is switching between the different devices. As already mentioned, the majority of the Internet users use at least one method of accessing the Internet. Therefore, by accepting and adapting to this trend, web creators can enhance user experience by allowing an almost seamless transition between the devices.

4. The conclusion.

One could draw from this experience that functionality plays an important role, when it comes to deciding whether or not to use RWD. The choice depends on various factors, such as the differences of content to be served across devices, the feasibility of adapting the website, such as time and resource constraints and even the number of people involved in maintaining the website.

Responsive website design has many advantages as well as weaknesses. It would be best used if the website was intended for a range of devices and the performance and loading time were not the primary concerns, although there was enough time to implement the RWD in such a way to not adversely affect them. Alternatively, it would be appropriate when the website was of as small size, which would still allow it to be loaded relatively quickly on a less capable device, such as mobile.

RWD also means that the web creator would have less code to maintain compared to multiple dedicated versions. The exception would be the initial set up of the required frameworks (i.e. the aforementioned Foresight.js) as well as selective choice of appropriate image sizes based on the screen size.

On the other hand, device specific versions would be a better solution for websites that have very specific functionality only either to a desktop, mobile, tablet device or even to all of those.

The most basic question to answer is whether or not the website needs to be responsive and is it worth making it so. The approach has certain benefits as well as the drawbacks and they need to be weighed carefully in order to determine whether to use the responsive web design or rather code for the specific devices.

This paper does not cover all of the implications of the device-agnostic responsive design. It is recommended to seek further information on issues, such as: browser compatibility, HTML5, choice of media queries techniques, approaches with flexible images and so on.