HN user

robflaherty

714 karma

Product designer and developer. https://parsnip.io/

Posts16
Comments28
View on HN

Always liked Reinertsen’s post on reframing tech debt to deferred work.

“When we refer to postponed work as technical debt this automatically biases us to assume that both ongoing and future costs are more certain than they really are. This, in turn, causes us to overestimate these costs, leading us to be overly cautious about deferring work. If it is your intention to bias the decision against postponement, this is clearly the best term to use. However, if you are trying to carefully weigh of pros and cons of postponing work, I’d recommend using a more neutral term like deferred work.”

http://reinertsenassociates.com/technical-debt-adding-math-m...

I know the intent is good (it is!) but this common notion that good design is a toolbox of fun little games really prevents the design function from getting taken more seriously. In the business world at least it ensures our seat at the kid’s table.

Worth remembering that priority and sequence are not quite the same thing.

There's a useful framework called RICE where you evaluate/score ideas by Reach, Impact, Confidence, and Effort. Sometimes assigning numeric values feels forced so I often use it as "dimensions to be thinking about" rather than a literal scoring system. [1]

There's some great stuff in Reinertsen's Flow book about different sequencing strategies and when to use each. Eg, When delay costs are homogeneous, do the shortest task first. When task durations are homogeneous, do the highest cost-of-delay task first.

[1] https://www.intercom.com/blog/rice-simple-prioritization-for...

The author's framework-"you just start small and only add one at a time as needed"-and given example illustrate exactly the process that leads to too many metrics. Pick a few metrics, add another, add another, add another. If you have 5 teams working on a product you quickly end up in the 50 metrics scenario.

Too many metrics can be a problem but it's not the real problem. The real problem is choosing metrics without any regard for the decisions they're supposed to inform.

When you understand that the purpose of all measurement in business is to reduce uncertainty for a decision to be made, everything comes into focus, and you'll have a natural constraint on your scope of measurement.

According to the ePrivacy Directive, they should not last longer than 12 months

The quote you keep referencing is false. The ePD says nothing about this.

Can you explain what is invalid about it? The list of functional cookie permissions on the consent opt-in specifically mentions cookies to remember log in details.

“Zoom cookies are firstly written when the user connects to the website zoom.us and accepts the cookies options.”

That was the moment Zoom received your consent to store data transmitted by cookies. Adding a few more cookies to the pile, regardless of expiration date, doesn’t change the agreement.

Rummaging round the cookie bin on uninstall is a nice find and deserves a raised eyebrow but this doesn’t really have anything to do with GDPR.

"I'd assume that for banks all code that goes into production gets audited"

The point of tag managers is to let non-developers update production without going through a code deployment so the usual code review and oversight doesn't apply.

Also worth keeping in mind that this is the bank's marketing site. It's almost surely managed by a different team than the actual online banking site and probably has looser restrictions.

I haven't tested it with infinite scroll but essentially it'll be a race. If the user can scroll to the bottom of the page before infinite scroll is able to load new content, the 100% event will fire. Otherwise it'll just register the previous scroll event (75% or a specified DOM element).

All engagement metrics are pretty loose. Scroll depth percentage doesn't tell the whole story but to the degree that scroll tracking is useful, I think percentage provides a simple, document-independent metric.

Btw, tracking scroll points for specific DOM elements is one of the plugin options, so for instance you could track the end of the .comments div as you mentioned.

Hi Brad,

Just wrote you back! You know, I actually don't see major publishers embracing responsive design, at least in the short term. I think mobile-specific sites and dedicated apps are much more inline with how they see the world. It's also a business opportunity for them to sell separate experiences as separate products, right? Merging everything into one isn't necessarily a win.

Hi, I'm the author of the post. The examples you mention are server side solutions requiring some form of server side detection. You're talking about serving ads to separate mobile and desktop sites.

The goal with responsive design is to serve the same site—the same mark-up, the same assets—to all devices. Which means that any conditional serving of ads has to happen client-side.

I agree that a comprehensive test would include the optimized scenarios that you mentioned. In this case the intent was to show that even when comparing two extremes - a very unoptimized page and a super-optimized page - the results were not as disparate as we'd expect. Scenarios involving sprites and domain sharding we'd probably expect to fall somewhere in the middle. Thanks for your comments.

Hi Jeremy, I'm the author of the post. The tests were not conducted locally, but over a real network, albeit a low-latency one. Latency is definitely a key factor, so I'm planning to run some more tests under different network conditions. Thanks for your feedback.