The list will look familiar to those of you who have already filled in our survey in preparation for the Ticketing Professionals Conference later this month. A big thank you to everyone who has helped out so far! It was really interesting to see how confident marketing and box office staff are (or aren't!) with these terms. Here's a quick explanation of each of these terms for those of you who were less sure of them.
Useful terms covered in the post:
- Data Migration
- Embedded Content
- PCI DSS
- Single Sign On
- SSL & Wildcard SSL
- Staging Site/Environment
API stands for Application Program Interface. An API is the way a technology provider (eg a ticketing platform) exposes their services and allow other suppliers to use them. The API documentation will outline what information can be accessed and how. This process can, for example, allow us to access live data about the availability of tickets from your ticketing provider, instead of relying on a regular update (via xml feed for example) which may quickly become out of date during a busy sales period.
In this example, an API gives us access to many different ticketing functions - some of which may be more important to you and some of which may be irrelevant. The first stage of the project will be to work out what you want your customers to be able to do, or access, via the website. We can then work with your ticketing supplier to find the best solutions for you within your budget.
Respondents to the survey were very confident that they understand what cache is. Which is great. But given that we get an average of 5 support queries a month which relate to cache, we wanted to cover it off here again - just in case. Most people are probably familiar with the cache in their web browsers as they will often get asked to clear it to see changes to their website. But there are many types of cache out there:
- a local level in your browser
- possibly also at a local level on your local (or corporate) network
- most likely at a wider network level as used by your ISP at the server level;
- and finally at the database (db) / CMS level
We've written in more detail about this already so if you want more info, you can find out more about web caching in this blog post.
Data migration is a process of moving data from one system into another. Often this is perceived to be less time intensive than doing a content load or data entry manually but this isn't always the case.
This perception probably comes from the fact that it's usually handled by different people - someone at your web agency rather than someone in a venue, for example.
This is content from another website or digital platform that is displayed within a webpage. For example, a Google map, a mailing list sign up form or your ticketing platforms purchase pathway on your website. Depending on the content that's being embedded, you may or may not have the ability to style the content so that it matches the style of the rest of the site. By embedding content from another provider, you are agreeing to honour their terms and conditions (which they may or may not enforce).
If you are embedding content then you need to be clear about who's responsible for what aspects of the webpage. For example, if you want to add new preferences to your mailing list sign up form, you need to set those up in Mailchimp/ Dotmailer/ whatever you're using, before the embedded code on the website can be updated.
Embedding YouTube or Vimeo videos on your website is a great way to ensure that your videos are searchable and also means you avoid having to host them on your website (which can be demanding - and expensive).
Using an iframe is a way of embedding content on your website. You'll most likely come across it if your ticketing platform integrates with your website. iFrames have upsides and downsides. They can be difficult to make responsive - putting fixed width content into an iframe on a responsive website will not make it work effectively on mobile - both products must be coded to work responsively alongside each other.
There are a number of browsers which will reject third party cookies (Safari and older versions of Internet Explorer do this by default). This can mean that an embedded purchase pathway won't work on certain devices (users can usually override those settings on their own devices but this cannot be changed centrally). There are ways that this issue can be mitigated against but you remain slightly at the mercy of your customers browser settings.
Loosely this is a way of describing that two or more different software systems can or will be set up to talk to each other/share information. There are different ways to do this. We've built sites to integrate with:
- CRM systems - most often ticketing or box office such as PatronBase, Spektrix, Tessitura, Tickets.Com and TopTix's SRO3 (PEO) and SR04 systems but also more dedicated CRM systems such as SalesForce
- event platforms such as Eventbrite
- email lists such as MailChimp, Campaign Monitor, Dotmailer
- social media such as Twitter, Facebook and Tint
- multimedia products like YouTube, Vimeo and SoundCloud
- fundraising tools such as Charity Checkout and JustGiving
- collections management systems - sometimes called digital asset management (DAM) such as Alfresco
- marketing automation platforms such as Marketo
- payment gateways and payment providers such as WorldPay and PayPal
- and more... there are tonnes of other products out there that could potentially be used.
While there is some commonality between many systems or web services (e.g. the means by which they expose or share their data) and moreover there is some commonality in how we work with them, every project is made different depending on the required level and sophistication of integration plus the workflow of an organisation - i.e. the particular setup, specific needs and known limitations of a client. So for example, we often get asked how other clients have done things and we can talk to that (we've been working on integration projects for almost 15 years, so we have a lot to say) but we always need to find ways to make sure that any integration project works in such a way as to support your customers and your staff, to make things as straightforward as possible AND within the allocated budget.
Stands for Payment Card Industry Data Security Standard. It's a system devised by the major branded card companies (Visa, MasterCard etc...) to help reduce credit card fraud both on and offline. There are 12 key requirements for PCI DSS compliance and most of the technical work falls to the payment gateway handling this sensitive data.
By using Drupal we can partner with a number of established, recognised and compliant payment gateways if your website requires it. Your bank may carry out checks on your systems to ensure that you comply and they may fine you if you don't.
Single Sign On (SSO)
Single sign on allows users to sign into two systems simultaneously and with one set of login details. If your website has a members section and online ticketing which requires an account, you don't want your customers to have to set up and remember multiple login details.
SSO can be a neat solution to get around this problem and help your customers have a better experience in their digital interactions with you.
SSL Certificate & Wildcard SSL
An SSL (secure socket layer) certificate provides a secure connection between the website users' internet browsers and websites. This means that a user can safely submit private details online to sign up to a mailing list or make an online transaction. You can tell if an SSL has been set up by looking at the address bar in your browser - secure sites display a padlock and possibly a green address bar (it depends which browser you're using). The SSL is installed on the server your website is hosted on and needs to be updated regularly - you can buy certificates for 1, 2, 5+ years.
An SSL is tied to the domain and server that's being used. If you have more than one domain which needs to be secured, then you can use a wildcard SSL instead. We have used this in collaboration with ticketing providers to ensure that the ticketing subdomain (eg tickets.tincan.co.uk) and the main site (eg www.tincan.co.uk) are both secure. Whilst a wildcard SSL is a little more expensive to buy, it does mean that you only have one certficate to renew each year and it works out cheaper than buying a certificate for each domain. Having a wildcard also means that if you brought another subdomain/project online - for example, fundraise.tincan.co.uk - you can use the existing certifcate.
See below for more info about subdomains.
A staging site is a copy of your live site - both the code and the content - which can be used as a testing ground for new work. It may be given other names and different set ups may vary - you might hear similar terms like test site, dev site, sandbox. Essentially it's a safe place where work can be done to try out new pieces of work, without interfering with your live site and affecting your customers experience of the site.
It's worth asking your ticketing provider if they offer something similar so that you can do thorough testing before putting new systems in front of your customers.
Let's use our domain as an example. The domain that we own is tincan.co.uk. We can set up as many or as few subdomains as we wish. Essentially these are like folders, belonging to the domain and they're easy to spot because they follow the same format. You can point each subdomain at a unique location so they can point at microsites or different systems. If we were a museum, we might set up the following (note these are examples, note recommendations):
- tickets.titled.co.uk - to host our online ticketing
- collections.titled.co.uk - to host our online collections database
- venue.titled.co.uk - for a microsite promoting our corporate venue hire options
- kids.titled.co.uk - for a microsite/project aimed at children
un.titled.co.uk is also a subdomain since it involved adding a prefix of un. to the beginning of the domain titled.co.uk. This is something to watch out for when setting various systems up.
This is how content is categorised and organised. It might be that a venues events are categorised as music, theatre or dance; that list would make up the taxonomy library for events.
If a website has filters on it then there will be a taxonomy library with preset options driving that filter. How things are classified should always be driven from the user perspective to make sure that it's useful and that the terms being used make sense.
Sometimes taxonomy is used 'behind the scenes' to control how or where information displays on a website.
If you think we've missed any terms from this list, tweet us and let us know! @undottitled