My response is very similar to noadavi's - Here's a mockup, which I'll follow by explaining the differences.
I've not applied any colour, as I don't want to convey information with it for accessibility reasons. Colour could easily be added, but it should be purely for visual interest, not as part of the message being conveyed.
I've included the brandname and address into two lines in the same cell, much as noadavi has. That provides more width, and they're effectively two parts of the same information from a user perspective - if a human being was looking for a place, they'd probably treat the name of the place as the first line of the address! (An assumption, of course, so worth checking with some research)
Variations to noadavi's approach:
- I've tweaked the presentation of cost to make it a narrower column
- I've kept the columns for parking, wifi, family room, but rather than using checkboxes, I'm using an icon to display the presence of those properties. The icons are aligned in columns, and with good alt-text they could convey similar meaning - I'm just using them instead of the checked version of your checkboxes, with a blank space instead of the unchecked versions.
- I've made the column header for those icon columns span those columns. The icons each convey the meaning of their column well enough.
- I've moved "good location" into the details... but I'm not 100% sure what's actually intended by it. Nobody is going to want to advertise "bad location", so I'd think hard about who's going to be benefit from that bit of info, and if it's going to be a reason people object to their data being present!
So, all of the data is there (except "discount" - I forgot it and don't have time to add it. It'd be another "detail") and it's in the same columns, but presented in a much more condensed way.
Noadavi also added a distance to the location column, which, if it's what "location" being good or bad is about (as opposed to "it's near a loud place" or "it's in an amazing setting") could be replicated here if the location column is put as the last of those icon columns. If it's the other kind of thing, those could also be broken out to icons for "quiet place" or "pretty place" - essentially a visual "tags" column.
Added 17/02/2017, following comments
Prompted by comments from Joao Carvalho below, I should clarify my reasons for moving "per night" out of the cost column header and into the data cells themselves. I have two such reasons for doing this.
- Column width - "per night" in the header forces the column to be much wider, and reducing width was the original goal of the question
- It adds flexibility to the design, in that it caters for accomodation which is available on a basis other than per-night. As an example, timeshares and holiday lets are often only available on a weekly basis and price scale - offering a daily rate for such things is counter-intuitive for somebody trying to book a short stay based on a daily rate.
But there is a trade-off. There are very strong reasons not to do it.
- It adds an extra step of interpretation and translation which the user must go through to be able to make a comparison between rows.
- If adds flexibility to the design, which means it makes it easier to misread, misinterpret or otherwise just plain confuse.
On balance, I would agree with Joao about the common time unit being better in most cases... but it doesn't help as much with compressing the width of the table and it risks user frustration if a per-night price is being offered when per-night accomodation is not an available option for that place.
If places are offered on different timescales, I would expect to see more done to make those timescales visually distinct from each other than I have shown here, but that distinction would be needed.