Should hubs have properties?

Software improvement
#1

Today we have properties for products & producers (organic, fair trade, biodynamic, etc.).
But should we also have properties for hubs?
Hubs can have different orientations: some can focus only on organic products, other only on local food (zero import), other can be logistics hubs, other food surplus redistribution hubs. Certain hubs can be BtoB (like supply restaurants for example using OFN), other BtoC, certain can require a membership, other not…

I think users may need to have some informations about the hubs before choosing in which they can buy. Of course there is the description of the hub, but maybe a “badge” can make some key properties of hubs more visible and easy to understand for users.

Discussion is open :slight_smile:

Initial set-up and configuration
#2

Others who run hubs will have more input that me, but one thought - if there are hubs that are B2B, it would seem important for this to be clear visibly (or filtered out even?) for citizens who are browsing hubs near them?

1 Like
#3

@pmackay Good point Paul! But maybe the “hub properties” could answer that need, as the landing page could be filtered by “BtoC” hubs as default, but with the possibility to select “BtoB”… or just click, like for products, of a combinations of properties for the hubs you are looking for (like BtoC + only local + certified organic for example… or BtoB + food surplus redistribution, if you want to start producing soup out of food surplus ;-))

#4

interesting . . I wonder where the line between ‘system set’ options like properties and ‘user set’ options like tags comes in . . @oeoeaio has just successfully installed a new tagging gem, initially enabling hub owners to set against customers (those who have shopped through their hubs) . .but then potentially applicable across the system, e.g. to products or enterprises

what are your thoughts on structured vs unstructured data for this use? e.g. should ofn super-admin of the instance decide what these properties are or should enterprises? and if you think the former, perhaps useful to start pulling together and discussing a list of the kinds of things you want?

#5

Hum… I think we should have a system set (by instance) to organize the categories so that we have a common backbone, but we can stay agile and adapt this backbone if needed … like if a hub doesn’t find the property that caracterize him, he can have a category “Don’t find myself there!” and pull a request to add a category; that way we can adapt the backbone on the go…
But if any entreprise can create new categories, then the searching system may become a bit “messy”…

I find the “tag” system very usefull for internal purpose, like in a hub, but I’m a bit afraid of the huge and messy list of tags if we show all the tags from all the hubs… each hub has it’s own way to “designate” something… But it’s hard to find the good balance between control (we don’t want to control) and organization (we want informations to be easy to search for)… So I would vote for a structured but agile backbone, and unstructured datas for each cells (hubs) connected to this backbone. But I’m looking forward to read other thoughts :slight_smile:

#6

are the hub properties necessarily different from the producer ones? or could we just add more to the producer property list and enable them to be added to non-producer enterprises?

#7

Having hub properties sounds useful. Maybe this is a terrible idea, but perhaps it could be connected to the hub’s admin panel, which could perhaps be simplified down to certain features or open other features (eg. buying club hub vs. food emporium vs. wholesale distributor).