Hacker News new | ask | show | jobs
by jordancolburn 3209 days ago
I appreciate the thorough response. It did make me stop and think about my assumptions. You present some convincing points,but I still come to the same conclusion because:

1. The sales stop showing after the first load and the values are saved in application storage. Why would they hide them if they are so valuable to the user. My guess is that users would be annoyed to constantly see these values and the users would catch on that they are only "recent" and not "realtime" sales

2. Why are the recent sales randomized in their location on the list. If it is such valuable info, why are they not placed at the top every time. Again, b/c users would ignore them and quickly learn they are not real-time sales.

3. If it so valuable to users, why not present it in a special location such as its own list. Why would useful pricing data be randomly put into the top of the list. Again, users don't really care so much about what recently sold as much unless it affects what is available now.

4. As SH, you have the option to show people recent sales, or how many tickets that are left. But to only show two recent sales and do it in a way that blends with other tickets is a deliberate choice to manipulate the user in a way that does not coincide with their expectation that those tickets shown to them on load where available when the page was loaded.

Basically, this "feature" was a combination of many design decisions and all of them lean toward cues to the user that these items are "real time" sales that just happened since we loaded the page, and away from helping the user realize the true nature of these sales. And of course it is done in a way that benefits stub hub and not the consumer, which is upsetting from a place that presents itself as a "marketplace", since users expect transparency from them (the price you list is the price, what I am told is available is available).

1 comments

Fair enough, and some of those are good points that I perhaps wasn't giving enough credence to, particularly the first. The others have weight, but I think that weight canby mostly or fully mitigated by common business or implementation reasons (as noted previously).