Hacker News new | past | comments | ask | show | jobs | submit | d4n3's comments login

Great idea... I don't mind paying for good games, but what i do mind is games that try to squeeze as much money out of you for just playing it, which fits your definition of bullshit games.

So unlockable DLC and removable ads are fine, but endless pay-to-win consumables aren't.

Sorting by number of reviews would be great - it's a better indicator of popularity than the review score


> The price is defined primarily by how much you ask for and what you can offer in return.

I couldn't agree more. I know a lot of developers that have the mentality to just accept what they are offered without negotiating. It's up to you to get a good price for the value you bring to the company. Negotiation is the best way to significantly increase your salary, regardless of your technical skills.

Patio said it best: http://www.kalzumeus.com/2012/01/23/salary-negotiation/


It seems like you're comparing current conversion rates vs. past conversion rates.. Did you try AB testing this side by side? It's not necessarily only the effect of image optimisation, could be just organic growth of your site?


I'm personally not going to A/B test larger webpage downloads for my customers.

Smaller is better & faster. There's no noticeable difference in image quality.

So my A/B test is 4 months before vs. 4 months after. This is not a small sample size. It's around 500k uniques on each end. 3M+ page views on each end.

I've also broken & analyzed the traffic down by channel, new vs return, and any other way I can to attempt to remove any false positives. From all the data, the large increase in conversion was because of this particular change.

I have been aware of "holiday shopping bias" around nov / dec, but January is normally a very shitty month for conversions. January / Feb our conversion was higher than any previous month before this as well.

This is actually why I've waited to Feb to really solidify the results in my own mind. And that's why there's 4 months of data to back it up. Every day since the change, being better than before.

I don't need to A/B test this one. The savings on my homepage was 4MB. We're not talking small bytes here. This is a major issue with regards to anyone using Shopify.

See if you can guess which month the change happened on this chart: http://i.imgur.com/S95EX9Q.png

Because I can see it.


> I'm personally not going to A/B test larger webpage downloads for my customers.

That's very sensible. But then you can't state that smaller images alone increased your conversion rate by 56%. Maybe your products are just more Winter-appropriate? If you can't control for confounding factors, you can't make a strong conclusion.

...On the other hand, in a contrived example, one could imagine smaller images could increase conversion rate by 1000% (if it cuts several minutes off the process; a website that takes 5 minutes to load will get no customers).

What I would like to see is an analysis of how much faster the shopping experience is post-compression. Perhaps for some of those edge cases (like your 250+ item shoppers)


Agreed, don't take 56% as fully being attributed to smaller page loads.

In two weeks after the change with out any other changes to traffic or anything else, the improvement was 38%.

I've talked about my findings with more caution here: https://ecommerce.shopify.com/c/ecommerce-discussion/t/shopi...

My worst day after this change, was better than my best day previous to this change. Thousands of visitors.

This trend has continued for 4 months after the change. Hundreds of thousands of visitors.

I'm the only dev on this project and I know what changes day to day.

Can full 56% be attributed? No. I added opt-in monster with 10% & 20% (A/B) discount in Feb which boosted conversions. 10% actually out performs 20%. Go figure.

Can more than 0% be attributed to smaller images. Yes. So I'd say this change helped between 0% and 56%. Either way, it's statistically significant.

4MB savings on homepage going to save you from a shit tonne of bounces and help move more people towards that checkout page.


I think this actually wasn't an arbitrary choice, but a result of the algorithm.. e.g. factors are displayed as clusters ordered in a circle (factors of 2 is a circle with groups of 2, factors of 3 is a circle of groups of 3).

So for primes, you have a circle of groups of 1.


Very cool visualization... I wonder how they get their data?


According to [1], they collected half a million photos from instagram, selected 20,000-30,000 photos from each city from that, then filtered the set down by using Mechanical Turk.

[1] http://selfiecity.net/#dataset


you could probably combine this with the font-face trick to target different letters


you could combine this with ::first-letter and custom selectors for each item of interest to get more specific data from targeted page elements...

If there was a way to target n-th letter in css, you could also get the full plaintext of an element with a huge number of font-face / selector combinations


> as they seem not fully aware of the standard order of conflict resolution

I'd say it's the other way around - a lot of usages of !important are due to lack of understanding of CSS specificity, usually as a symptom of something else like using IDs in selectors..

If you avoid using IDs in selectors and avoid deep nesting of classes, then overriding styles works as you expect - apply a more specific selector to override the style.

Selector order only comes in to play rarely, and you can structure your files to start with less specific (base) styles first.

I see !important as more of a workaround than a solution, and I don't think it is used as it was originally intended.


I was talking more specifically from a debugging perspective as most of the frustration and anti-!important sentiment in the community stems from the effort and time taken in the process to fix a layout issue only to find after a half an hour of mental exercise and acrobatics an !important flag was raised somewhere and hence was this unexpected layout behavior.

I'd say that people who debug this way are at fault here not the language itself or this specific methodology followed because the order of cascading and inheritance in CSS is as follows: importance, origin, specificity and finally source order.

So, people who debug layout issue shouldn't jump first to diagnose specificity problems but importance and to lesser extent the origin albeit it's less common now to encounter a prob in this domain, and when everything is clear, you go and inspect specificity and source order.

That's why I am not sold on the complete avoidance of !important when writing CSS but I am of the opinion that you should only use them when necessary when you need to override a certain style in a very specific context and not more.


Chrome devtools sort selectors by specificity by default and you can quickly see what order the selectors / properties were applied in and what overrided what.

Most of the !important uses I've seen are more due to "Why doesn't this work? Dunno, I'll just put !important on it.."

Since !important only applies to a specific property, it's not that useful for making structured CSS components, and makes it harder to override (using !important again on every property)

I can't think of many cases where using !important would be better than overriding with specificity. Maybe when using 3rd party styles or making styles that are embedded in an external page (e.g. widgets).


There' a user switcher button in the top right corner, you can have multiple browser sessions with seperate histories / cookies (e.g. work / personal)


Holy moley! I never noticed that!


Right, with lots of elements, React still needs to render and diff each component which for a lot of elements causes a lot of garbage and diffing work. ShouldComponentUpdate / PureRenderMixin avoids this altogether when props/state isn't changed so this gives a significant boost with lots of elements.


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

Search: