4

I'm developing a dashboard for hotel managament system application.

There's a view that allows the user to set prices for room types in different currencies. Sadly, I can't provide any screenshots as it's still in development.

I don't really like the idea of placing multiple small inputs for each room type (Given 10 room types in a hotel with 10 available currencies, I would have to place 100 inputs). Unfortunately, prices can't be calculated automatically with exchange rates.

I'd love to make this both self-evident and clean for the end user.

In short - how to nicely present a large number of inputs so that the user doesn't get scared.

If you need any more information or some quick mockup, please let me know. Any help much appreciated!

Quick mock

Improve this question
3
  • 1
    A mockup is always useful, just to make sure we're not going down the wrong track with any answers here.
    – JonW ♦
    Jan 22, 2013 at 12:45
  • 1
    Is is a requirement that the user be able to see and edit all prices for all room types in a single view?
    – Matt Obee
    Jan 22, 2013 at 12:55
  • 1
    Sadly, the application's architecture would make it hard to set prices from under, i.e particular roomtype view. Prices are part of offers(periods). Quick mockup incoming.
    – Michał Rakowski
    Jan 22, 2013 at 13:06

2 Answers 2

Reset to default
1

Since having 100 inputs is unavoidable, I would do a 10 x 10 grid with each row alternating in colour. For example the row colours could alternate between white and a very light gray to give each row visual distinction, and so the user will not lose the row he is on.

A different option to using alternating colours is to use line separators, like the https://ux.stackexchange.com/ homepage. Just make sure to give enough vertical spacing to keep the rows visually separated.

If the user is at all technically savvy, they will most likely use tab key to skip from field to field, so making sure tabbing flows in a logical manner for the user would be key.

Improve this answer
1
  • I've decided to create extendable, accordion-like containers for roomtypes to ease up the "input noise" a little. If I'm not satisfied I'll make it a table like you suggested, thanks!
    – Michał Rakowski
    Jan 22, 2013 at 13:47
0

Perhaps each room type could be calculated off a multiple of a base price?

E.g.

For USD:
Base price = $100 USD.
Room Type A = 1x base price = $100 USD
Room Type B = 1.3x base price = $100 USD
Room Type C = 1.5x base price = $150 USD

For AUD:
Base price = $95 AUD.
Room Type A = 1x base price = $95 AUD
Room Type B = 1.3x base price = $123.5 AUD
Room Type C = 1.5x base price = $142.5 AUD

This would allow the user to set a base price for each currency, which means they would only have to fill out 10 fields as opposed to 100. You would need another screen for them to change the base multipliers when the prices of rooms do change in relation to each other, but at least for the majority of the time, when currencies change they can far fewer fields, just 1 for each currency.

Edit

I just realised a simpler way (for the user) of doing this. If you can have the 10 prices in USD set, the user could then just just manually punch in the exchange rate for the other 9 currencies, and your application could then calculate the prices based off that.

I am making a big assumption that the hotel wants to directly convert the price from your native currency (which I've also assumed is USD), as using this method will not allow them to set unique prices for each currency.

Improve this answer
3
  • 1
    Hello, sadly the specification I recieved says that the user wants and must be able to set each price to whatever he wants, regardless of currency exchange rates and so on. As much as I'd love to use your solution, here my hands are quite tied.
    – Michał Rakowski
    Jan 22, 2013 at 13:09
  • 1
    If that's the case, it seems like having 100 inputs is unavoidable.
    – Rich
    Jan 22, 2013 at 13:12
  • 2
    It seems to me that even if you allow editing all prices in all currencies, it would still make sense to provide sane default values based on a calculation off a base price. Perhaps instead of just applying the currency conversion, you can find out what kind of rounding of prices is usually prefered. For instance, the hotel may want to round a price of €115.38 (US$150) down to €109.99 or up to €119 for marketing reasons. Figure that out, and your users will probably find themselves editing the prices way less manually...
    – André
    Jan 25, 2013 at 12:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.