šŸ’” Feedback
Open

a modest reflection/proposal on object-based properties + expediting the setting-up

I have tried for years, but after that feel there is a kind of obvious net-disadvantage to the ways the setting-up of object-based properties (obp“s) is treated.

It“s a small thing in a way, but also hugely consequential to anyone using object interrelation in Capacties via leveraging the fab affordance to built properties based on other object types:

when naming an object relation based on *one specific* object type, there is no way of auto-assigning (via pre-population etc) the title of the new object-based property. One has to re-assign/customize that anew from blank panels each and every time.

Now some reasons why that is really a) counter-intuitive, and b) counter-practical:

• actually, when setting up obpĀ“s the way Capacities handles the structure there is only a 1:1 relationship anyways; meaning obpĀ“s will always by neccessity be non-ambisuous in what property/properties they relate to

• coming up with a label should be open to re-assigning other labels (for creativity, flexibility and other systematic reasons) – but it is the most probable default in most cases that the label will be identical (or at least highly) similar to the referenced objects name (bec otherwise the field would be self-occluding!)

• now, the setting up of this field is not only a little laborious and fiddly but itĀ“s also – IME – the no. 1 source of the whole process (of setting up a new obp) failing… just because the panel can slip away so easily bec of many reasons, throwing one back to start anew…

So, overall: while there is reason to leave the process open to renaming, it“s overall net-non-productive to force 're-inventing the wheel' (label) on the user each and everytime, causing diff things like extra-work, straying of naming, fault-suspectibilities etc.

This net-negative of being forced through a more or less artificial/unneccessary (re-)naming-process (that is for the bulk/majority of cases) reroduces and proliferates on higher levels of being a net-negative. That is bec it bars another possibility/potential route in the flow-architecture of setting up objects more easily: multi-selecting object properties for any new object in one go!

This would be conceivable in cases where picking objects as base/reference for a property is more automatic (automatic in terms of *softly* prescribed, like in auto-populating the field).

But this would also make so much sense in terms of the Capacities logic and standards: just bec it has been statet that shared object properties btw objects is not really intended (for reasons of team + Capacities philosophy). This is fine in itself. But closing off the opportunity to replicate object-property profiles/sets btw objects (along w/ object-propoperty profiles in general) should make it even more desirable to make the setting up of object properties easy and 'cheap' for the users ('cheap' in the senses of cognitively, processually, labour-input wise and ergonomically 'cheap').

So, this is a plea for reviewing this old entrenched way – and – hopefully – 'modernizing', streamlining it and thus levelling things up and making things much-much easier for users (power-users as casual users alike, with each 'type' benefitting the same if for slightly different reasons…).

Please! šŸ™ šŸ‘ļø šŸ‘ļø

0 Comments

Sign in to comment

No comments yet. Be the first to share your thoughts!