Hacker News Reader

Comment by Sharlin | Hacker News Reader

Seriously, UI components are hard. Even a lowly button is difficult to get right, where ”right” means ”whatever smart people have converged on after 30 years of GUIs”. Anything more complex than a button is much much harder. There are a lot of things wrong with the whole ”web app” concept but to me maybe the most important is everybody trying to implement their UI widgets from scratch. And I say this as someone whose job used to be writing and maintaining a webapp UI framework.

View on HN

Right, but you don't need "smart people to converge on" an agreement as to whether or not the 2nd of February is a Thursday. That would seem to be pretty well-defined.

Well it's likely the client/server time-zone mismatch was the cause here. It could be that everyone at AirAsia, or even the majority of passengers, saw the right dates, and this edge case was simply not considered.

Assuming a timezone mismatch, it wouldn't always show up because the date would have to cross a midnight boundary for the days to be different. Even if we assumed the servers used Malaysia time rather than UTC, that leaves 8 hours in a day where North American travelers could see the right day.

Time zone shenanigans or not, it has nothing to do with UX. 2/2 is not on Thursday, anywhere in the world, period. This is simply an obvious bug and a lack of customer service, not some UI failing because UI is "really hard".

Are you aware that dates does not get influenced by timezones, right? And not only that: Thursday was January 31. Friday was February 1. Saturday was February 2.

They got it wrong by 2 days.

Feb 2 0019 is Thursday. Off by 2000 years.

I like how you think ;-)

More seriously, that would be a Y2K bug that took close to 20 years to discover, which I think is basically impossible.

We need to find out the date the original poster actually entered to make the booking. They may have entered 2/2/19. Perhaps the code for the calendar interpreted it literally (as year 0019) while the code to display the date string did a conversion for Y2K.

> Are you aware that dates does not get influenced by timezones, right?

Yeah, but the situation is worse than that. Weeks boundaries are influenced by a locale. What is the first day of the week? Sunday? Monday? I know that in russia a week starts with a monday. I know also that in en locales it is not the case, I was never able to understand english calendars, so the very first thing I do is fixing locale to see a "proper" calendar which I can understand.

Notice that there are no hints where is sunday and where is monday, you make a decision what is what based on data layout in a two-dimensional grid. For example, I read the screenshot in the tweet as Feb 2 is a Friday, not Thursday.

This leads me to a hypothesis what happened with AirAsia. They messed up locale dependant calculation of a week boundary. Like they added 1 instead of subtracting it, or maybe they applied the locale dependant shift of a week bondary twice, or made some other software bug like that.

They have weekday labels, just click through on Twitter to see the uncropped image

Well defined, Gregorian? You're kidding right?

Sure it's "defined", but it's full of hacks to deal with whims of fancy.

Even the day of the week calculation is borderline moronic.

Yeah every other travel site seems to at least show you the proper date range. Let's not make excuses for shitty work, a date picker component isn't an NP Complete problem.

My comment was not meant to be an apology of any sort at all. Quite the opposite! Not all datepickers are as broken as this one, but that doesn’t mean the situation where everyone keeps reinventing things is a good one.

It is not.

Though, it’s interesting to note that once when I took a date picker component and attempted to morph it into a full-blown MacOS calendar, with calendar appointments that slot into different time slots and don’t overlap, I found that that is an NP-Hard bin packing problem.

>Let's not make excuses for shitty work, a date picker component isn't an NP Complete problem.

...how would one even define a complexity class for date picker components?

Very much this. I work on a "web app" with all custom components, even the most basic input is a custom component... everything about it sucks. Keyboard navigation sucks and is redone poorly, dropdowns are godawful, styling them is no joy.

I don't know what our way out of this is. Everyone imagines their own UX and wants this or that thing to behave differently from everything else out there on the web. We'd have more usable webpages (and web apps) if we didn't spend most of our time reinventing the button... over and over and over

If Web Components don't save us, nothing will.

Thankfully I'm pretty bullish on them (especially customized built-in elements.) The future is bright.

I've heard about this but I'm not so sure. From my limited experience, the customization is as bad or worse than say React components. And then there's the whole shady/shadow DOM. And from my experience the way that components are currently used, "slots" can get you in a lot of trouble. This is without mentioning the severe fragmentation in that space (polymer vs skatejs vs stencil vs ....)

Shadow DOM v0 was kind of a mess (the fragmentation you mention), but v1 kinda washed all that bad taste away and is a pretty sane API. I don't see libraries building on a feature as "fragmentation," however.

Slots are a powerful feature that has to be used carefully. But it's a great API foundation for a lib (which is a tendency for web platform drafts, ex. WebGL and Web Audio.)

Customization is just CSS, I'm not sure about the comparison to React. For Shadow DOM styling, we're almost at the point where the last big problem (selective and scalable piercing styles) are getting solved.

In any case, the world is better with Web Components than without. Combine them with ES Modules and you have an great ideal for the web platform to strive towards.

I do hope to see them picked up. I'd like to see the next Bootstrap/Foundation/Material UI framework be web components, that'd be a sight

to me maybe the most important is everybody trying to implement their UI widgets from scratch

I see stopping efforts to roll one's own UI components unnecessarily as a rite of passage for a developer.

I think rolling your own datepicker is an important rite of passage. So is learning why you shouldn't use your hand-rolled component in production.

Agree, IMHO virtually always one should pick HTML5 components or something that is very mature, otherwise a lot of care is needed for something that works everywhere.

On the other hand, the guy is aware of the concept of a date picker and misuses a third party website's calendar for his own. This is a bit naive.

Admitting you made a mistake and making it right isn't hard if you care about your customers.

Assuming that Air Asia's customer support's purpose is to care about customers, rather than enforce policy.

It seems the more legacy a business is, the more defensive and less proactive its customer service remit becomes (e.g. insurance and telecom).

UI components might be hard, but typing <input type="date"> into a HTML document is not hard, and it's enough for the browser to do the right thing here. This screwup was entirely self-inflicted, a consequence of ignoring the well-known best practices of authoring semantically-meaningful web documents, forms and apps.

That's currently only supported by 86% of browsers. A few years ago when they might have designed it, that number as much lower.

See https://caniuse.com/#feat=input-datetime

Regarding input type="date"

> Recommendation

> While convenient where it works, the failure mode of type="date" and its associated date and time types is very poor. This makes it a risky choice that could leave users struggling to meet validation criteria.

[0]: https://www.smashingmagazine.com/2019/01/html5-input-types/#...

I remember desktop Chrome ‘implementing’ date input a few years ago by using the number input’s spinner. If you press up the date goes to 0000-01-01. It was worse than useless because you can’t even polyfill in a JS datepicker since the usual feature detection would detect Chrome as having support for date input.

For better or worse, 99.9% of the web uses custom datepickers, if not for other reason than the fact that <input type=date> is not supported by all the browsers out there.

Sometimes the client want different look and behaviour for componet, not Just the simple HTML5 input

As evidenced by this example: in such cases, the client is probably wrong. They'd be better off letting the user agent display the date picker that the user is used to.

Don't conflate the simple fact that there is an outright bug here with the presumption that the browser's date picker would be a better choice.

Even in the event that a browser ships a buggy date picker, at least it would be buggy on every website. The user then has a chance of understanding the bug and working around it to input the correct date.

OK, I'll use another tactic. Show me a single high-traffic travel website that uses the browser's default date picker. Travel websites are usually optimized out the wazoo because small increases in conversion rates make all the difference in this competitive business. Are you saying all those sites (the ones without bugs) are wrong?

The user is responsible for their browser. If they choose to use something that doesn't implement the spec and your site breaks, they sabotaged their own experience. That's very different to you sabotaging their experience.

This type of mindset is not conducive to creating a successful business. Or creating good websites in general.

Most users aren’t _choosing_ their browser, in fact they probably don’t even know what a “browser” is, relative to the “web” and the “internet”. If they’re using even a somewhat modern desktop/phone/tablet and things don’t Just Work it’s probably your fault, not theirs.

If it's a "best-practice", I honestly don't know any large, consumer-facing websites that just use input type=date, mainly because that UI sucks in most cases.

Even in this case putting the dollar amounts in the dates, which is a very useful piece of information, would need a custom date control.

Is that even a web browser? If you look at the full screenshot, (I'm not 100% familiar with iOS) it looks like an app launched from the app store?

That’s almost certainly an app; a web app would require quite a bit of configuration to look like that. It might be running a web view internally, though.

Good UI is hard, but it's also a solved problem since at least 25 years and idiots keep reinventing "solutions" the wrong way over and over again. I see developers frequently make mistakes that Windows 95 got right.

Yes, this was my point. Desktop environments have standard sets of battle-hardened components for good reasons.

No, you're all making them hard. It was no problem to book a flight in 2005.

Reply on news.ycombinator.com