Ski holiday sites – suggested improvements

Earlier this year I promised myself that I’d at least try to work with certain people that I was really interested in and was passionate about, either because of the subject matter or the nature of the work that they were doing. As a one-(wo)man-band it’s often quite hard to get a foot in the door with people who just don’t want to speak to anyone but full service agencies, or don’t publish lines of communication, but I’m a firm believer in things not happening unless you try. So I tried to get in touch with several organisations, but sadly didn’t hear back from them at all. Despite this, I thought I’d try to do something productive regardless.

The companies that I’d contacted in this specific instance were ski holiday companies. There was one big one that I didn’t get in touch with, out of respect for a friend’s company having a pre-existing interest, and I didn’t want to muddy the waters there at all. I’d had a chat with my friend when he had mentioned that particular company, during which I’d realised that there is a lot that these type of websites just aren’t doing. Every year I struggle through using a set of sites which simply don’t match the way that I look for or want to book a ski holiday, and so I thought I’d do something about it. I’d get in touch and try to help them out.

After not hearing back, it would be easy to go “well, sod ‘em”, and wait until next season, when I will inevitably have the same frustrations. I chose to do something a bit different though. As such, here are some of my thoughts on some of the main things ski holiday companies should be doing differently on their websites.

These thoughts are obviously out there now and whilst it would be really nice to be credited if they get used, I’m a realist! However, if you’re reading this and work for a ski holiday company, or for an agency that works with one, and would like me to work with you properly on this, please do get in touch. There’s only so much I can solve without knowing the realities of your business, your users, and your systems, and I would really love to help make some of these happen.

So what needs to change?

Ski holiday sites are focused on one thing – getting people to book holidays. As a holiday booker you need to find a thing you like, and pay for it. Therefore the search and booking functionality are critical, yet are often the areas with the biggest problems for users. They’re also areas that have huge technical implications, which is often the reason why things don’t get changed lightly.

This is also why I’m particularly interested in sorting out some of these sites, because this kind of merging of technology with how to better serve users is right up my street. At a high level there are a few key areas that we can look at:

• Front-end changes to how the user is shown information, and how they are able to interact with it
• Change to search logic (what can be searched for, how, how this may impact on API/database etc)
• Change to booking logic
• Change to, or addition of external data sources
• Amendments to content management system in order to better support the new processes.

It’s hard to go into any detail without knowing any of the detail about anyone’s actual setup, which is why I’d love the opportunity to be brought in formally to investigate. I’ll talk about the realities of this all at the end of this post.

This post is also going to be long enough as it is, so I’m going to focus here on the search, and potential third party data sources.

That being said…

I also need to state the obvious, in that a lot of the big players in this industry haven’t gone responsive yet.

  

(Yes, I like tabs)

Inghams has, but it feels like a bit of a half-finished experience – see for example the footer, which hasn’t really been tailored for this size of display, just squished. Plus once you choose a holiday and head through to book.inghams.co.uk, the site jumps back to being a ‘full’ experience – right when you need to get to grips with fiddly radio buttons!

Ecommerce sites are still seen as a challenge to do responsively for some reason, although this shouldn’t be the case at all. There are numerous examples of how embracing RWD principles can bring huge uplifts in conversion. As usual the @rwd twitter account run by Ethan Marcotte is a great reference for case studies. Here’s one recent one:

“Sixty days after we launched the new site…mobile revenue increased 107.65%.” @electricpulp on responsive ecommerce: http://t.co/qZ3gstAnv4

— Responsive Design (@RWD) April 3, 2014

It would be great if some of these sites could adapt to a variety of screen sizes, but also if they could do more than this, and really embrace the wider principles of responsiveness, as well as progressive enhancement.

Ok, let’s find a holiday!

Now, I’m not going to start waffling on about how I feel these sites should be presented or what the key end to end processes could look like. What I am going to do, is aim to spark a bit of thought around how certain modules and bits of functionality could be improved. Let’s start with searching.

I’m also not going to cover every ski holiday provider, but instead am focusing on a few of the big players. The current processes look like this:

Thomson Ski

The homepage, and sidebar used as a booking method throughout the site requires the following. This is as it is presented on page load, and where there are pre-filled values these items are mandatory.

There are alternate routes to booking, through browsing resorts, deals, or holiday types, but eventually you end up entering a subset of the above.

Crystal

Crystal, being owned by the same group, has exactly the same search mechanism.

What they have done fairly recently though, is to bring in homepage modules allowing you to search by the skill of your party members, and by certain criteria such as “less than 2 hour transfer”. This then suggests several resorts that you may like. There’s also a promo linking to their Snow Reports section, where you are able to check the current snow levels and forecasts, again by resort.

Neilson

This site takes a slightly different approach. As they also provide beach holidays and sailing, there is a radio button to make the search ski specific, but otherwise it’s pretty much the same as above. I’ll spare you the image.

Again it starts with when you’re going, Where To? (Anywhere is permitted), and How Long For? (Don’t mind, or 7). Where From (Any is included), how many rooms, and the number of adults/children make up the rest of the form, meaning that this is instantly a lot more open a search than the previous two. It is also possible to reach the booking stage through browsing other site content.

Inghams

Inghams has done something interesting. They’ve introduced some huge imagery, and an extremely simply initial search step, simply “Where can we take you?”, and “When?”. When using this last season, I particularly liked that the Where element also allowed variants (I believe I was able to search by a particular extended ski area – “Paradiski”, for example, covering Les Arcs and La Plagne) however now this only appears to allow the selection of a single hotel option, rather than an area. Typing “Obergurgl” – the resort I went to in March, will not allow me to proceed. I suspect this may have something to do with availability (we’re at the end of the season and they’re probably booked up), as deeper within the site, on choosing a country, you are presented with a list of resorts that includes the ability to search by wider areas.

So what’s the problem?

The searches are all very, very linear. You usually enter a set of values, maybe modify them, but then get to a point where if you need something else, you have to input everything right from the start. There is a huge assumption being made that the person searching already knows some element of what they want – either where to go, or when, and from where. This places the burden of research on them right from the start, and tends to lead to them going off to read up on things, or to go through the booking process multiple times, trying different options.

Me, me, me

We all know that building for ourselves isn’t the best way, but humour me here as I think my frustrations can highlight some important points.

My personal experience is that I’ll start thinking about skiing as the year closes out, maybe in November. I like going in March because it’s usually sunny and it’s my birthday then. I like Austria, and I don’t like sitting on coaches for hours. I’m a lazy skier and don’t want to be doing ‘hard’ things all the time, but equally I like to roam around and love expansive areas. I’m not sure how long I want to go for – that kind of depends on price, and maybe times of flights – I like to know if there’s more available to me than the usual 7 days. I’d like ski in/ski out if at all possible, but if not I’d like to be near a main lift. I hate getting up at 3am to catch planes.

How does that translate though into the boxes I’m presented with? It doesn’t.

Forcing me to pick a date means that I’m going to have to go through the process again and again, trying all of the dates that I can do. I’ll actually save the variables and end cost into a spreadsheet in an attempt to look for the best options.

Whilst I like Austria, I’m not against other countries. I’d actually consider multiples from the list, but because I’m not able to specify this, instead I have to repeat my search for each one. With country repetitions combined with my date repetitions, we’re now into a lot of permutations. I’m not sure where to go though – there are certain things about a resort that I need to know before I want to check out prices, so actually I’m going to have to go away and decide on this before I can understand how much anything might cost.

Likewise with airports. I prefer Stansted as it’s close to my house, however I can do any London airport, so if you’re giving me that combined option then great. However, some of the sites offer the snow train from St Pancras. I’ve never done this, but I’d consider it. Again, having to search for this as a separate option introduces yet more repetitions.

What does this translate into?

You’re probably starting to get the picture. There are some things that stand out simply from my own experiences that would really help when searching. Things like:

Search by snow levels

It’s great that Crystal have brought this in as a search route, as this was a major problem when looking for a holiday this year. Several places that we were wanting to go to just hadn’t had any snow, but it was only through third party sites that we saw how dangerously low some of them were. I personally use Snow Forecast, which has a great set of information, although no public API, but again, this is putting the burden of research on the holiday booker rather than helping them out proactively by showing them the best options for snow.

The limitation with the Crystal search is that it’s just within a dedicated section. By cross-referencing the information with the actual holidays, the search could be made even better. Rather than searching by snow levels, going into the resort, then finding hotels, then maybe looking at another resort separately, introducing snow level as its own parameter into the general search would allow for direct results from different resorts, including filtering by other search parameters.

Neilson also have some snow report information, sourced from from the Ski Club of Great Britain, although it’s very tabular and dry. They do have your classic Javascript snow effect on the page though. Seems snow effects are for life, not just for Christmas.

Inghams again have some data, but in a separate section. It’s not clear who provides this, but it’s great that they’ve added some additional context by providing video reports alongside the general stats.

Thomson don’t appear to be allowed to share the Crystal data, and there is no obvious snow data section.

Crystal are using data from the Ski Club of Great Britain and On The Snow, but sadly they don’t publicise information about their APIs either, so we can’t see how or what you can search. The former has some fantastic data on their site though, so it’s likely that we could grab most of, if not all of this:

Snow report by resort:

• Last snowed (date)
• Amount snowed in the last 7 days (in cm)
• Current snow depth on upper piste (in cm)
• Current snow depth on lower piste (in cm)

** Forecast by resort:**

• Current weather
• Next 9 days
• Current snow depth on upper piste (in cm)
• Current snow depth on lower piste (in cm)

There is a comparison function for resorts, returning:

• Current snow depth on upper piste (in cm)
• Current snow depth on lower piste (in cm)
• Last snowed (date)
• Amount of snow in the last 7 days (in cm)
• ‘Historical’ upper piste level (in cm) – no definition provided for ‘historical’ here
• ‘Historical’ lower piste level (in cm)
• Current temperature
• Current weather

Historical data by resort:

Gives the ability to plot the following by resort graphically as well as in a table:

• Upper piste depth
• Lower piste depth
• Fresh snow (daily)
• Maximum temperature

Data can be compared by resort, and filtered by season and the week.

On the Snow provides similar data, but also has the ability to provide ‘powder dump alerts’ (although it’s again not clear if this is exposed through an API). If it was, this is something that could be integrated into automated mailshot alerts for the holiday company.

The above is all fantastic information, and whilst some of the sites seem to expose it, nobody seems to be making the most of it. Why not, right at the start of the search process, allow people to choose “I want to go somewhere with over 1m of snow on the upper slopes“? This will be particularly useful at the end of the season for late deals, or as with me this season, booking somewhere with over a ‘safe’ amount on the upper slopes meant that even a ridiculous amount of melt over a couple of months would still leave us with enough to be good.

Historical data wouldn’t necessarily need to be obtained via an external API on an on-going basis. Whilst it may need to be sourced externally initially, it obviously won’t be changing, so could simply be imported once and referenced by the local application rather than requesting it from the third party source. Moving into the future, any data collected could also be stored – for example logging of snow levels at the end of each month would negate needing to request historical data for this month in the future.

However as a word of caution, it’s important to say that if information is exposed via an API, it’s important to establish whether there are any usage restrictions. Data providers are often unwilling for third parties to expose it in ways that exactly mirror how they use it, so whilst it may be possible to do some great data visualisations in theory (and this is something I’d love to see more holiday companies doing more of), in practice it may not be possible.

Don’t make people specify too much if they don’t know

Whilst Inghams’ ability to search for a ski area (rather than re-searching for each resort within a larger area covered by a single lift pass) is great (if it’s still there…), what would really be helpful is if this could be expanded to work a bit harder.

It would be great to be able to select multiple countries or resorts, or a mixture. Likewise, it would be great to say “I want to go anywhere BUT Bulgaria or Andorra”.

Also, all of the searches fixate on dates. Other travel websites embrace the concept of “I’m flexible”, and I don’t see why ski holiday sites should be any different. Having the option to pick a date range, or to see price trends over time would be great – even a maximum and minimum price per month, for example.

Search by transfer time

Again, Crystal have this half there, with their little homepage widget, however I’d like this to be integrated into the main search. “I don’t care where I go, as long as I spend less than X hours on a coach once I get off a plane” could well be an option in the main search, rather than being a step to find a resort, which then has to be put back into the search module by the user.

It’s worth noting that Inghams do have this as a second step to refine results, and do allow you to select ‘All countries’ and then ‘Short transfers’, effectively giving the same option. None of the others do however, and the way that this is presented could be done a bit better, even specifically exposing that option as a callout/promo, collecting together all of the holidays that match.

School holidays

This year I went skiing over my birthday, because for once I could actually go on the day itself. It was only once getting out there that I realised that it was a school holiday somewhere in Europe. For some, school holidays are a great time to take the family away. For people like me, they mean busy lifts and annoying kids who are MUCH better at me in snow parks and who laugh when I fall off the boxes. I like to avoid them. I usually check sites like School Holidays Europe, but if I ran a ski website I’d look to speak to people like this, see if they were willing to expose their data to me, and in turn use it to give context to information on my website. “Prices are high this week – that’s because it’s half term in Austria”. Users could be warned that certain dates may go fast, creating that much-desired sense of urgency, or could simply be shown a small “FYI it’s half term in France this week, just so you know” hint. aka FOR THE LOVE OF GOD BOOK ANOTHER TIME!

Ability to compare different options

As much as they have served me well, I’d really like to be able to do away with my nerdy spreadsheet approach. What would be great is if you were able to save search criteria, and to see a list of your options displayed alongside the price. Yes, prices change. But this way I can keep track of it from within my profile. As a website owner you’re also encouraging sign-ups this way, and getting people to create a profile pre-booking, which most simply won’t do at the moment.

A more cut down version of this would be to introduce comparison elements within search results. For example if I have selected to depart from Gatwick, Heathrow, Stansted or St Pancras, I’d like to see the different cost and time implications within my search results, rather than having to perform multiple searches.

This would be pretty simple to implement in the scheme of things. As long as the search schema is established, storing a set of parameters and values against a user ID wouldn’t be complex. It could also allow for the introduction of “price alerts”, used in many travel and ecommerce sites, again allowing for engagement with the customer, reminding them to return, and providing that last bit of incentive to go for the holiday.

Features are important

Inghams again does quite well, as with the ’short transfers’ above – once you have given them your initial criteria you’re able to filter your results by features such as high altitude/guaranteed snow, ski in ski out, or car parking. They also offer other filters such as whether the hotel is family friendly, whether wifi is available, or even if child menus are available.

Neilson is very limited in this respect, offering only a ‘family friendly’ checkbox, and requiring the user to go into the hotel page to get further detail.

Crystal and Thomson do offer some filtering, although these appear to be subjective (‘Best for families/groups/single travellers/apres’), and heavily focussed around Crystal’s own holiday types (Finest etc), or offers that they have on rather than facts. Doorstep skiing is included in the list, as is swimming pool or wellness facilities, but not much else.

Thomson includes a subset of the crystal options – the standard board basis, plus the set of doorstep skiing/swimming pool and wellness found on the Crystal site, but that’s it.

Being able to associate additional features to site content will help it resonate more with users. This doesn’t have to be just around resorts or hotels however. As mentioned, introducing seasonal data such as weather trends, snowfall, or even half term dates could help people get to their holiday much more quickly.

In technical terms, this could potentially be a challenge if the back-end responsible for the attributes of bookings available is inflexible, and does not allow for the addition of such meta data easily. It is usually possible to tie editorial content to such records, however consideration would need to be given to how searches then work – is information from both stores amalgamated, and our search actually looks at this data set rather than at the source of the booking information? Prices would be an obvious exception to this, as any kind of caching could introduce inaccuracies. The editorial challenge would also be a considerable undertaking – the more information is provided to users, the more has to be gathered and input.

Improved piste maps

As well as snow levels, I will always study an area’s piste map before even considering any hotels. I don’t care how nice your chalet is – if you’ve just got two runs in your resort, and both require a 20 minute drag lift to get to the top, I’m probably not interested. Maps on ski holiday sites are generally poor. Here’s a good one, for base-level comparison with the below.

Neilson tends to hide theirs within a carousel, obviously cutting off most information.

Thomson and Crystal both provide the same cut off version (Crystal’s implementation being a bit buggy), with a link to download a full version or a click/tap action to open it in a new window. Sadly however this is one without any of the detail found on a ‘proper’ map as you may pick up on the mountain, but at least it gives you an idea.

Inghams yet again use the joy of a carousel to convey some of the piste map.

Maps are frequently out of date too. It’s an editorial challenge, but making sure that high quality piste maps are able to be uploaded at the start of each season should be a content management priority. Offering high quality, clear images that have the same information as in-resort maps should be an absolute priority. Having these easily accessible, especially when grading the quality of runs for different levels of skiers, will really help people get a feel for the resort they’re looking at.

Make the data sexy!

All of the sites tend to provide a dizzying array of statistics, but these are just put on the page in a very dry way. I’ve already talked about how I’d love to see more snow data surfaced in an attractive way (that’s why we’re all there after all), but other information could be made more useful too.

Resort height, total km of piste, number of runs, number of lifts, longest run, number of restaurants – this is all great stuff. How about comparing it to the average for the country and displaying a comparison? How about providing more context – “Longest run is Schattberg at 7km. This takes most people about 20 minutes”.

A lot of resorts are now introducing apps. I have previously written about the Skiline app, and this season used two new ones, the local iObergurgl app, and MapToSnow which appears to mainly cover the Austrian/German/Swiss resorts. Partnering with such a provider and introducing user-generated data could provide some great data about most popular runs this month, how much time people spend a day on the slopes (compared to other resorts), and even things like top speeds achieved. It could also be a separate channel for engagement if these companies were to offer their customers exclusive offers by partnering with such providers.

Where’s my hotel?

Walking in ski boots isn’t fun. Ok, it’s a bit fun. (You can pretend you’re a giant mech warrior, or you can try to moonwalk). But when you’re carrying skis, and you’re ever so slightly hungover from the 8 mugs of gluhwein you thought it would be good to drink before bed, you’re going to want to get back out there as quickly as possible.

Hotel descriptions are usually poor. Case in point “Central location. 2 minutes walk to Reiterkogelbahn ski lift” from the Thomson site. Having stayed at the hotel this description is from, I know that it’s 2 minutes, up a road that has a lot of traffic, which is up a pretty steep hill.

Providing something like a Google map doesn’t give you all of that context, but it’s a start. A flat view gives you an idea where you are in relation to the main lifts. If Street View is available, even better, however Google Earth in this instance gives us a better idea of the fact that we’ll be walking up a hill.

The red dotted lines in the Google Maps image are lifts, and the blue lines are runs into the village.

It’s possible to embed both Google Maps and Earth data via their respective APIs, although it’s worth considering that rate limits and usage restrictions both apply. There are several other data sources available, so often the decision is down to how you feel about Google’s services, how much traffic you have, what other strategic relationships are in place, etc.

This information would help the user be better informed, but it’s also worth considering gathering feedback from users and displaying this. Many companies send out questionnaires about the holiday. Gathering information on the closest lifts, and location of the hotel in general could be done through this channel as well as by asking for it on the page. This could then lead to modules such as ‘Top 5 closest hotels to the lifts’, or ‘Top 5 quietest hotels’ (i.e. furthest away from that awful club…), again allowing information that already likely exists to be presented in useful ways.

What is the technical impact?

As I mentioned previously, it’s hard to write some of this because it strays dangerously close into an area that I don’t always like – the speculative redesign. My problems with these are that they’re usually founded on complete blue sky thinking, which can be dangerous when it’s not grounded in any realism, and can lead to issues with mis-communication.

However, I think that a lot of this is possible. External data sources are out there, as evidenced by them already being used. Exactly what data is available to be exposed, and how it can be used, will depend on the nature of the contracts in place, but there’s some great opportunities there. A lot of people are doing some of the things I’ve talked about, but they’re halfway there, and there doesn’t seem to be any joined-up strategy across the site with regards to the possibilities available.

I’m a big believer in responsive principles where appropriate, and I don’t see anything on these sites which makes me think it wouldn’t work. Booking engines may need to be dealt with separately – the jarring experience on the Inghams site for example when transitioning to book suggests that there are likely additional complexities around this, possibly due to legacy systems, third party limitations, or areas where there was not previously budget to address. In a real project, identifying all of these areas and discussing how best to integrate them would be a key task very early on. This is a huge area, and I have a lot to say on the matter for each of the companies discussed here, but suffice to say that there are definite improvements to be made in this area, particularly around both the technical side and things that would be more useful to people booking holidays.

And the big one – amending search. From what I’ve seen, the date and country search data will be the sticking point. I imagine that calls have been set up with these as the minimum parameters, and that any change to these would require re-writing of some (probably really legacy) systems. From prior experience of working with people like Eurotunnel on making changes to internal systems, these kind of changes can be made, but only with the right attitudes from management, and sometimes lengthy development schedules or cost to the organisation. My recommendation in this area would be to identify how the system works at the moment, what calls can be made, what format the data is in, and whether it can be extended to store new suggestions that have been made. Performance will be key, and balancing this with the realities of the search setup will likely be a big challenge. New calls could be architected, both with specific functionality and processes in mind, but also flexibility for the future – i.e. not restricting input types to a single value, like how country searches clearly are at the moment. This would need to be a big collaboration between a mixed team – technical decisions should not be made without user experience input, and vice versa.

In conclusion

This is all very much from personal experience, but I think there’s something here, and some great opportunities for ski holiday companies to shift their thinking a bit. I’m by no means underestimating the amount of work needed to bring in some of these changes, but I think that if you really want to support how your customers want to engage with you, you need to be prepared to try to push on with your technology, not just be held back by current limitations.

As at the start of this huge post, I’d love to try to make some of this happen, so if anyone would like to get in touch regarding working together you can reach me at sally@recordssoundthesame.com.