Programmers are inherently encouraged to be lazy, so they'll follow the easiest path assuming you're careful to actively encourage that... if you're not really careful about exactly how "obvious" you make your intended path (Hint: It's never obvious enough) then you wander by a few weeks later and there's a giant Rube-Goldberg construct blooming in source control.
We have a similar app, Flatmin (http://flatmin.com) that's targeted more specifically at shared living situations.
We built it a few years ago, and h(ave|ad) big plans to expand into household chores and shopping lists. It's an interesting problem from a couple of perspectives. We've found the more Facebook integration we can do, the better as the target market are very comfortable with Facebook.
It's also a difficult one to make money from - we have some ads on there, but I think to really make it work you'd need integration with another app or some kind of freemium offering (daily deals?)
Yours looks nice - if I could make a suggestion, it would be great to enter email addresses of people to invite, as sending them a hex string is less common and more likely to get lost!
Obviously it would be nice not to be rude to people who, after all, are working on something that benefits you, if you are prepared to call other people out like this:
May be slightly off-topic, but I feel a little pain behind my eyes whenever I see the hack-around-namespaces function naming (e.g tt_whatever, for "ThumbTack" presumably).
Surely a singleton class would be a nicer way to do this (or just leave the "tt_" off, why is it necessary, you're not overriding core functions)?
When aggregating stats in this manner (by Day) how do people deal with Time Zones?
For instance, if I have one user in, say, NZST, their "Tuesday, 22 February" is still "Monday, 21 February" in PST - and the real issue is that the buckets are off. So you can't just store in UTC and then move it by whatever timezone offset, as then you are grabbing different "buckets".
I don't think that explanation is very clear (I had to draw a diagram to figure it out myself). Hopefully someone smarter than I am can figure it out anyway.
We've worked around it by just storing hour aggregates, but I'm interested in case someone else has a smart solution :)
Be careful with this. We've used it on a number of sites, and whilst overall it's beneficial, there are a number of weird things to watch out for.
For instance:
- Don't add rounded corners to a <table> element - this will crash at least IE7 on XP
- Don't try to rounded corners an element you've hidden with the "left offset" technique (position: absolute; left: -9999px;). This will crash at least IE7 on XP.
I think there a few others I have since erased from my brain due to IE-induced PTSD. YMMV.
I think there's a more succinct explanation of this somewhere, but I think people usually overvalue their own contribution whilst simulataneously undervaluing that of others (see: http://books.google.com/books?id=YywIHNBn_YEC&lpg=PA147&...).
So perhaps it's the cynic in me, but I would expect people to be justifying their own importance. I do agree with you though - it should be the reverse!
We've talked about adding more information about the market in general, and that's the intent of the blog (blog.200square.co.nz), but it's not very prominent at the moment.
You would definitely be able to see it first! You'd just organise a suitable viewing time with the owner (you can send messages back and forth using the system)
Hmmm - we had kept it like that to be focused on the seller - there's more buyer info under the "buy" tab. We hadn't considered the "traction" angle. I'll bring it up with the others - thanks!
As per all generic advice, YMMV.