Custom Property sets

Now that I’m catching on to how these work at present, I thought I’d raise a design question.

I had assumed that most custom property sets would be smaller than the default set, involving only the properties the the user might want to change. I envisioned that the user would start by duplicating the default set, then deleting unwanted properties. I also assumed the ability to move selected properties from the default set to the custom set at a later time.

It looks like the current model has all properties in all sets. That definitely makes it easier to program the new feature and make it robust. There’s a down side, though, in convenience for the user (and a small hit in storage, speed, and efficiency). One advantage I looked forward to in custom prop sets was not having to wade through that long list of properties for the one I want.

The current setup is very cool and I can definitely live it, but I thought I’d mention the possiblity of smaller custom sets. In SPForm, there are over 70 properties and I envisioned a custom set with < 10.

If we do keep the full sets, the "remove property" popup should be disabled when editing a custom set and when editing the default set, it should give a warning that the property will be deleted from all sets.

Quote from: BobRay at Dec 18, 2008, 03:02 PM

It looks like the current model has all properties in all sets.

It doesn’t, technically. It only overlays (or rather, underlays) all the default properties for that element underneath each custom set. This allows you to quickly see what properties you can change in that custom set, without having to toggle back and forth between the default and the custom set. Properties in green are default properties that are overridden in the custom set; properties in purple are properties that are not in the default, but in the custom set.

(and a small hit in storage, speed, and efficiency).

Nope. Only the new or overridden properties are stored in the database.

If we do keep the full sets, the "remove property" popup should be disabled when editing a custom set

Fair enough, but only for default properties, not new ones.

and when editing the default set, it should give a warning that the property will be deleted from all sets.

Ah, but it won’t be - when a property is deleted from the default, it wont be deleted in custom sets - we decided not to do this because this might cause problems for upgradability, degradation, etc.


I agree, it is at first different than one might surmise - but in the latest revision, I’ve added plenty of text to inform the user what exactly the colors on the property names mean.

Now, if you’d want, we could add a toggle to hide default properties when viewing a custom property set - that might help. File a ticket in JIRA if you’d like that.

Ok, I get it now that I’ve seen the new message on the property set edit screen.

It’s a fantastic feature. I hope people will be able to understand it without a lot of extra help. It’s confusing that the colors don’t show (in FF anyway) until after the set is saved. I think toggling the default properties in and out might make it even more confusing.

I think it might work better if the default properties (or the custom properties) were set off more clearly. Maybe render the defaults in a lighter gray (italic?) and then change them to solid black or Bold when they’re overrides and blue when they’re added properties not in the default set. It would also help, IMO, if there was a different background color for all properties actually *in* the custom set. Part of the problem is that we’re already using red and green for yes/no values on the right side so the user has to remember what the colors mean *and* which side of the grid they’re supposed to be looking at. If they change a yes/no value in a custom set, they’ll see a color change on the right and another one on the left after they save the properties. It would help users get the concept if the difference between the custom and default items went all the way across the grid. It seems conceptually wrong to toggle just the color of the text in the name field.

It’s also confusing that you can remove properties from a custom set by right-clicking on them and selecting "remove property." They disappear as you expect them to, but when you save the properties it looks like they’ve come back. How about making remove available only for added properties (in the custom set but not the default set)?

Also, the "save properties" button scrolls off the screen with a long list of properties, but the "save" button is still visible. I’m not sure what happens (or should happen) if you click on an element’s "save" button when editing a custom property set and then navigate away.

BTW, what about making it so there was no way to edit or delete the properties in the actual default set? It would be easy to edit them by accident and have no way to get back to the real defaults. Since we’ve gone this way (custom property sets), I don’t see the need to edit the default properties. It would be *really* nice as a developer to know that the properties I set as defaults were still all there and unchanged when it was time to upgrade. And it would be useful to be able to tell users to set everything back the the default values and know for sure what would happen. Otherwise, I’d expect a lot of support questions based on problems caused by users editing the default properties (and claiming they haven’t) that will be a real pain to get to the bottom of.

Let me know if you want any of all of these ideas in Jira and whether you want them as separate issues or as subtasks.

Quote from: BobRay at Dec 19, 2008, 12:03 AM

It’s a fantastic feature. I hope people will be able to understand it without a lot of extra help. It’s confusing that the colors don’t show (in FF anyway) until after the set is saved.

I can fix that.

I think it might work better if the default properties (or the custom properties) were set off more clearly. Maybe render the defaults in a lighter gray (italic?) and then change them to solid black or Bold when they’re overrides and blue when they’re added properties not in the default set.

You think users would be able to distinguish between gray and black? Maybe bold - I’ll try it out today.

It would also help, IMO, if there was a different background color for all properties actually *in* the custom set. Part of the problem is that we’re already using red and green for yes/no values on the right side so the user has to remember what the colors mean *and* which side of the grid they’re supposed to be looking at. If they change a yes/no value in a custom set, they’ll see a color change on the right and another one on the left after they save the properties. It would help users get the concept if the difference between the custom and default items went all the way across the grid. It seems conceptually wrong to toggle just the color of the text in the name field.

Rendering-wise, that gets really difficult to do. I’ll keep that in mind.

It’s also confusing that you can remove properties from a custom set by right-clicking on them and selecting "remove property." They disappear as you expect them to, but when you save the properties it looks like they’ve come back. How about making remove available only for added properties (in the custom set but not the default set)?

Fair enough.

Also, the "save properties" button scrolls off the screen with a long list of properties, but the "save" button is still visible. I’m not sure what happens (or should happen) if you click on an element’s "save" button when editing a custom property set and then navigate away.

It will automatically save the set. Save Custom Set only saves the set, while Save saves both the element and the set.

BTW, what about making it so there was no way to edit or delete the properties in the actual default set? It would be easy to edit them by accident and have no way to get back to the real defaults. Since we’ve gone this way (custom property sets), I don’t see the need to edit the default properties. It would be *really* nice as a developer to know that the properties I set as defaults were still all there and unchanged when it was time to upgrade. And it would be useful to be able to tell users to set everything back the the default values and know for sure what would happen. Otherwise, I’d expect a lot of support questions based on problems caused by users editing the default properties (and claiming they haven’t) that will be a real pain to get to the bottom of.

While that sounds like a good idea, I have one concern - what about people who are trying to create a snippet from inside the manager? How would they go about adding and removing default properties? That concept works good for downloaded packages, but not for snippets made in the manager alone.

Let me know if you want any of all of these ideas in Jira and whether you want them as separate issues or as subtasks.

Anything you can put in JIRA is a good thing. I’ll just close or resolve stuff that’s already done or not applicable.

Quote from: splittingred at Dec 19, 2008, 08:59 AM

BTW, what about making it so there was no way to edit or delete the properties in the actual default set? It would be easy to edit them by accident and have no way to get back to the real defaults. Since we’ve gone this way (custom property sets), I don’t see the need to edit the default properties. It would be *really* nice as a developer to know that the properties I set as defaults were still all there and unchanged when it was time to upgrade. And it would be useful to be able to tell users to set everything back the the default values and know for sure what would happen. Otherwise, I’d expect a lot of support questions based on problems caused by users editing the default properties (and claiming they haven’t) that will be a real pain to get to the bottom of.

While that sounds like a good idea, I have one concern - what about people who are trying to create a snippet from inside the manager? How would they go about adding and removing default properties? That concept works good for downloaded packages, but not for snippets made in the manager alone.

Good point. I hadn’t thought of that. What about bringing back the old "lock" checkbox? That would help keep us from changing them accidentally and it would let us keep non-admin manager users from changing the default set while letting them edit the custom ones.

Quote from: BobRay at Dec 19, 2008, 11:41 AM

Good point. I hadn’t thought of that. What about bringing back the old "lock" checkbox? That would help keep us from changing them accidentally and it would let us keep non-admin manager users from changing the default set while letting them edit the custom ones.

Sounds like a JIRA feature request. That may or not make it into beta - that’s a pretty difficult feature, but I’ll see what we can do.

Quote from: splittingred at Dec 19, 2008, 11:46 AM

Quote from: BobRay at Dec 19, 2008, 11:41 AM

Good point. I hadn’t thought of that. What about bringing back the old "lock" checkbox? That would help keep us from changing them accidentally and it would let us keep non-admin manager users from changing the default set while letting them edit the custom ones.

Sounds like a JIRA feature request. . .

Done.