Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What? No. Why would you put a weird palm tree icon on a marker instead of the price? I know it's warm in the Mediterranean, I'm not an idiot so please don't treat me like one. Also, why does it matter where the user is located and what the temperature is there? I know where I am (which, in many cases is different from where I plan to fly out of) and I can probably figure out the local temperature if I need to, which I don't when booking a flight.

Also, "icon-driven" navigation? In other words, confusing pictures that I have to think about instead of clear text. Drop the icons and the interface actually gets more minimalist (since the text is there anyway).

How in the world did design get to this point? It's like somebody decided that the Internet was too convenient and efficient and asked a bunch of designers to figure out ways to make it harder to use instead of fixing the actual problems that exist... (an example of which would be the date dropdowns on travel web sites, let me either select a date or type in a free-form date that gets parsed smartly).



If I type in '02/03/2013' is that the 3rd of February or the 2nd of March?


That really isn't the type of input I was thinking of, though certainly that is a fairly easy problem to solve in a variety of ways. I'm more interested in being able to say something like 'Aug 2' or 'next Thursday', the way I can in Google Calendar.


> I'm more interested in being able to say something like 'Aug 2' or 'next Thursday', the way I can in Google Calendar.

And in Hipmunk.


Oh hey, that does work! I hadn't noticed that, good for them! Their calendar dropdown is also superior to most others in that it isn't a popover-style context menu but has been integrated into the interface so that I can see a visual representation of the dates I've chosen.

Now if only their site wasn't completely broken on mobile... :(


> Now if only their site wasn't completely broken on mobile... :(

Yas, sadly you have to use the app for that.


I fly twice a year. Why the hell would I want an app for a flight booking company? It's this sort of mentality that really gets my goat when it comes to mobile.


This is precisely our way of thinking at adioso.com


A good design will actually specify the format (mm/dd/yyyy or dd/mm/yyyy) or just let you use a date picker/calendar. So no confusions there.


I just want to note that only americans use the mm/dd/yyyy and that it's pretty non-logical. So no problem outside the US.


Times and dates are already non-logical. 24 hours in a day but 7 days in a week? Some months have more or less days than other months? Seriously?

http://infiniteundo.com/post/25326999628/falsehoods-programm...

http://infiniteundo.com/post/25509354022/more-falsehoods-pro...


I don't get how this is non-logical compared to what I said earlier. 24hour is the same excuse as the empirical system, you can divide 12 by 2,3,4,6 thus it makes things easier. It's a different system than the metric one, we could have said that a day lasted 100hours and week 10days. It doesn't make it non-logical though, it's like changing the basis.

But ordering makes things logical.


OK, so the "non-logical" argument is irrelevant. But the "this is only in the USA" argument still stands.


The original comment I replied to was suggesting that the date picker was a bad thing. My point is that it's better than any other method, since parsing a date correctly for all people in all situations in the way implied in that post is not possible. There will always be ambiguity over the date if the user chooses to use 'dd/mm/yyyy' or 'mm/dd/yyyy'. Chaking location, or locale isn't much use - we brits go to America on occasion, and they come over here. If you mark it as [dd/mm/yyyy] then you've just limited the usefulness of 'a free-form date that gets parsed smartly'.


You would handle that by looking at looking at a user's location settings and choosing the appropriate one. For example, if we detect your IP is in Germany, we would prompt "Would you like to see this site in German and change the currency to Euros?" If you say yes, then we would also localize the date formats.


> You would handle that by looking at looking at a user's location settings and choosing the appropriate one.

Great, now if I try to book a flight from Spain to Hungary while being in the US for some reason, I'm pretty much guaranteed to get the one date format which makes no sense whatsoever.


If you were in the US, we would use US conventions unless you had specified that you picked a different localized site (let's say the .es site) in which case we would switch to the conventions based on localization settings.


> If you were in the US, we would use US conventions

Which is precisely the problem I'm pointing out.


I'm from the UK, so if I'm in the US looking to get home, I see the dates the opposite way around? A better way would be to look at the user's locale.


Did your browser ask for en_GB or en_US or fr_FR or whichever localization? What is your IP? With those two info, I can make an educated guess and print out the expected format mask near the input box.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: