tommikaikkonen

The demo video is great, I would consider putting it higher up on the page and possibly on autoplay. I wonder when Amazon will integrate LLM into the native reader. Nice work!

I think that's natural and OK. I would compare writing my thesis to writing my first full application after learning how to read and write code—even after several iterations under a skilled supervisor, the codebase is still going to have a more or less fledgling and awkward quality to it, even if the functionality proves useful. The second attempt takes less effort and results in higher quality output.

Similar to how few people would put their first application out in public, I prefer to keep my thesis private unless someone finds the information really useful :)

Thanks. The thesis is really mediocre academically, so I don't feel comfortable putting it out in the public, but if you leave an email address here or contact me through Twitter I'll gladly send it to you.

Agreed. I think this kind of research can give ideas on what kind of experiments to run on pricing pages, but there are so many factors affecting real life plan choice that everyone should have their own A/B testing setup to see what works for them specifically.

I did my MSc thesis on SaaS pricing pages. I'll share what I found, since I think many people in this thread may find it useful.

I tested how Mechanical Turkers (N=~400) chose plans on pricing pages with 4-tiered subscriptions plans, for both a file sharing service and a payroll software service. Each respondent was randomly assigned to one of 4 conditions, where the presented pricing page was slightly different. The scenario was framed as choosing a SaaS plan for a company they're employed at.

The first variable I varied was plan order. Half the respondents saw a pricing page with plans in increasing price order (cheapest first), the other half in decreasing price order (most expensive first). There was a statistically significant difference between the plan choices for these groups; respondents in the most expensive plan first condition chose a more expensive plan. This phenomenon has been seen before outside SaaS, and it's called the price order effect.

Another variable I tested was exchanging the cheapest ($5) plan for a free plan. Half the respondents saw a free plan, the other half a $5 plan. There was no statistically significant difference in the plan choice for these groups.

Getting familiar with previous literature, I would surface a couple of general thoughts:

- The most expensive plan first approach may give the visitor a more expensive image of the product, a higher "reference price". If a prospective customer is comparing two products from two different companies, they may favor the one that seems cheaper (has a lower "reference price") even if the offerings may provide similar value.

- The hypothesized mechanism for the price order effect is that you don't look at all the options as a whole, but you begin by assessing the first option, which is the leftmost one for us reading left-to-right, and then judge the next option by comparing it to the previous one, and so on. You compare added (more features/less cost) and lost (less features/more cost) value. Because we weigh losses heavier than benefits, there's an inertia toward the initial options. Only options with benefits that greatly outweigh losses combat that inertia. Hence respondents tended to choose plans more on the left.

I've migrated a lot of code from moment to date-fns because of moment's bulky size and vast, mutable API. Luxon seems to fix the API issue. date-fns is still great for simple operations, but I'll definitely consider this for new projects with nontrivial datetime handling.

How does this compare to elasticsearch-dsl?

Where can I order a physical copy?

What was the optimization?

I agree, that doesn't look bad. However, this type definition forces you to supply one argument per function call, which looks awful in JavaScript:

    fn(1)(2)(3)

That's a big drawback for me. Libraries like Ramda allow one or more arguments per function call:

    fn(1, 2, 3) === fn(1, 2)(3) === fn(1)(2, 3)

That's what makes the verbosity unbearable, as each type of call needs its own type.

Currying in JavaScript is really nice if you can remember the arities of each curried function you're using. If you forget to call up to the last argument, you'll be passing a curried function instead of the expected value, and it can throw an error really far away from the bug. And instead of normal data to inspect at the error site to point you to the bad call, you'll only have a generic function name to look at. I've spent more hours than I'd like to admit debugging these situations.

A type system would detect these cases, but TypeScript and Flow don't have great support for curried functions. Typing them is very verbose.