Search

This section concerns two mechanisms, the user keyword search, and the set of filters which can be applied to make results more relevent

• A quick keyword search will search offers / wants, personal descriptions and perhaps previous transactions (if the user has permission to see them) on the basis of keyword. This might be the only way the user can see beyond the groups, currencies and localities of which he or she is a member.
• Search will be performed within the context of the currenly selected filter

Filters

To allow a system to become large, and to feel smaller, there will be a number of run-time filters in the system which can be enabled in the site configuration. This will provide users with a choice of which way to slice the bulk of accounts in the system for their own purposes. For example, some might want to look at local accounts for a cat feeder, while others might be looking to trade in a more esoteric currency, regardless of geography; still others will want to search the notices in a specific category. There also needs to be support for creating arbitrary groups. Each of these might make a good plug-in, filtering the accounts table before displaying members. And the system would work before most of them are written.

1. The choice of available filters will be set up at runtime. Some filters may be applied by the system, for example so that people trading in different currencies might never see each other.
2. If any filters are available, users will choose which filter they want to apply to their listings.
3. Listings include: directory listings of people or skills belonging to people, listings of messages, listings of trades, any statistics/reporting widgets such as top ten earners...
4. The concept could be extended so that when a user looks at an account history, even that is just a filter. Though this might not be an intuitive way to design the Graphic User Interface.

Examples of filters

1. Currencies - membership is restricted according to criteria defined by the currency creator. In order to transact, both people need to have accounts in a common currency. Membership to currencies can be restricted by some other dimensions, though it will be mostly open.
2. Localities - refers to a line in your address. Localities nest, so that by being a member of Brixton locality, I am automatically a member of South London locality. Membership of localities is involuntary, and depends on your address. This is good for caring structures, and for easily finding trading partners within an accessible distance in a spread out scheme. Each locality, for the purpose of mapping, would have a centre and a radius
3. Groups - can be created arbitrarily. We don't have a meaning for them yet. We don't know what membership criteria might be. For example, this might be the way to have an invitation-only dimension. This dimension should cover all other dimensions needed but not built in to the system.
4. Radial - this is just an idea at the moment, but based on postcodes and therefore geo-coordinates, people could make their own localities based on distance from them. This would better serve people living on the borders of localities. Membership would be according to the distance between the person who's radius it is, and everyone else. Typically members would save their preferred radius and view directory listings or maps accordingly.
5. Offer-categories - there are opportunities to create spontaneous communities amongst, say, all the caterers in a system, by regarding offer-categories as a dimension. membership would depend on what skills and services a person was offering, and which categories they fell into. Example, I might be clearing out my garden shed, and I might want to email all the gardeners within five miles to see who needs any tools.
6. Buddies / nonbuddies -Buddies are designated friends, or trusted people.
7. No filter - search the whole system. This will be the obvious choice for most small systems.
8. Myself - show only transactions / messages whatever in which the current account participated.