Work out the "nearest neighbours" (in terms of overlap of properties viewed) which then allows people to become a "swarm", a group of local people that could share information/comments etc about the area they are interest in

Some properties marked with a little man don't show any changes when viewed

From http://www.property-bee.com/forum/viewtopic.php?f=15&t=771&start=45#p3471

ClareMac;
Having cleared all my little men from the Sidebar yesterday I noticed I had quite a few back today, about 20. When I checked them though, about a third of them show a price reduction etc. on 25th October as expected but the rest show nothing new e.g. the last date showing any change being April.

BH reply;
Just had a look (again) and think I've found something, not sure it explains every rouge little man - but it may explain some of them!

One of the properties you viewed was at "2009-10-25 20:33:28" (user_properties.last_viewed in the server db) however the change you found when viewing is logged at "2009-10-25 20:33:29" (rightmove_samples_recent.sampled_on in the server db), ie a second later.

Overnight the cron job runs, and generates notifications for all properties where user_properties.last_viewed is before rightmove_samples_recent.sampled_on .. which is true in this case even tho you found the change, and when you click on the property, no new change is seen.

Not 100% sure of the reason, it maybe
* comparing up the date/time generated by the toolbar with date/times generated by the server
* that the server time is being used but ticks over from 28 seconds to 29 seconds between updating the 2 tables

From speakers:
I've just started using PB with prime location, after a couple of days a few of the properties on the sidebar had been removed from prime location yet were still showing as available on the sidebar.

From BH:
When a property listing is no longer available, the generic page http://primelocation.com/property-not-available/ [^] is displayed, which doesn't include a reference number.

This causes us a problem, as we are unable to mark the relevent property as "Not listed".

The only way I can see is

* tracking which page is being requested (by clicking the sidebar row) and trying to associated with the actual page loaded - this is something the current design doesn't do, plus it won't work if the user browsed the property from a bookmark.

* try and get the location of the page before the redirect, maybe its in the window.history?

"When you click on what will become an unlisted property in the sidebar, daft shows a box at the top of the page and suggests similar properties.

The problem for PB is that page there's no reference number in the html to identify the unlisted property, and so Pb doesn't pickup that you have tried to look at that property, so it doesn't clear the litlle man."

Formalise and improve the interface between the user interface / XPCOM component

At the moment the interface between the user interface and XPCOM component is a little haphazard/incomplete, eg
* duplicate methods providing property info to the sidebar/history table
* incomplete use of observer or signals&slots to keep the user interface up to date with the latest informations (whether property info or toolbar config)

Formalising/improving the interface will
* allow the user interface to be extended without need to constantly update the XPCom component
* lead to better understanding/requirements of what the XPCOM component needs to do internally (for a future release)

A new user registering using an existing username displays a load of html rather then "username is already in use"

If a new user tries to register with someone elses username, for some unknonw reason the error message being displayed is the html about an insert failing, rather than "Sorry the username is in use by someone else" I'd expect to see.