cairo140

Testing it out as a user, the slide transitions didn't feel as responsive to swipe velocity as I expected. In particular, if I swipe even a small distance but quickly, I expect to trigger the transition. I just tested it with iOS and Android, and they both seem to do it at least for left-to-right transitions of home screen pages, and Android does it for the top menu.

From looking at [the source](https://github.com/kenwheeler/slick/blob/master/slick/slick....), it doesn't seem check for velocity; it just applies a distance threshold. Have you considered having the threshold respond to swipe speed so that faster swipes over shorter distances trigger transitions?

Some analysis on the comparison of the two systems.

This system chooses all streams (one play by one user of one track) equally, rather than by treating all subscriptions (one user) equally.

When you treat all streams equally, you effectively make a system where users who listen to the most streams have their weight felt the most.

For instance, consider this world with two users.

[User 1 listens to artist A once a month]

[User 2 listens to artist B five times a month]

Under the Spotify stream-based system, artist B is awarded five times as many royalties as artist A. This might be seen as "fair" in that royalties are paid out depending on the proportion of value/happiness/"utility" created, assuming each stream produces the same unit of value.

Under an alternative user-based system, artist A and artist B are awarded equally. This might be seen as "fair" in that royalties map as directly as possible to the user fees. It sees users 1 and 2 as equally satisfied through their bare use of the service, regardless of the number of streams they've consumed.

People generally want to see systems where value creation is proportionately awarded. Under that goal, which model is "better" depends on how you map value to streams and users. That's the core problem... also consider some complicating factors like users gaming the system by spam-streaming artists they want to support or the value associated with stream consumption by free users (a large part of Spotify's user base).

I've enjoyed a, for lack of a better term, per-sprint billing cycle. It lies somewhere between all of the techniques on the page and has worked the best for my past client base (startups creating MVPs, companies that need relatively stand-alone websites and services).

You bill by sprint (2 weeks; expectation of full-time), planning for a set of deliverables with approximate story weight among them. This gives the client something concrete that you're building towards and gives me incentive to actually produce value and not get mired in non-value-producing things like tweaking styles or excessively mulling over long-term architecture and deployment. Also, it has sufficient room for the inevitable adjustment to scope mid-sprint (although I found this was rare; perhaps 1/4 of my sprints experienced this). We'd just estimate the new work that gets introduced and pick off an equally weighted task, no fuss.

My clients found the level of certainty reassuring, and the bug flow of deliverables at the sprint pace was very satisfying, especially to clients who are used to project-scale deliverables. I also found it was conducive to producing better overall software. The sprints made us work together to constrain our thinking to the most valuable things to do in that time horizon. For my specific client base, it left us flexibility to adjust to acquisitions, major project-level scope changes, and financial circumstances, which typically only happened at a biweekly sprint pace.