When you set up a cck field, you have to add both a human readable name, and a machine readable name. We're in the process of moving this to the same screen (they're currently split over two forms). When on the same screen, it'd be nice to auto-fill the machine readable name from the human readable name - i.e. "news" becomes [field_]news.

So two things:

1. strip disallowed characters from the human readable name
2. use this to pre-fill the machine readable textfield (there's a similar technique in the D6 installer for admin e-mail).

Comments

karens’s picture

Title: DROP task: Add autocomplete suggestion for "machine readable name" » UMN Usability / DROP task: Add autocomplete suggestion for "machine readable name"
Component: content.module » Usability
yoroy’s picture

Does the machine readable formfield have to be shown by default at all?

Why not initially hide it and let a script parse a machine readable version of the 'normal' name?
This machine readable version could still be displayed, maybe something like the password strength feedback in core:
____________________________________

name: *
[my gr3@t txtfield!!1] (machine readable: mygrttxtfield)
____________________________________

If you click to edit another standard textfield is added underneath:

____________________________________

name: *
[ ]

machine readable name: *
[ ]
____________________________________

karens’s picture

Not completely sure I understand the example, but the machine readable name must be editable. This is because there are situations when you want to control what it is, something that has come up often in the past. We also have to check whether the name is available or already taken before using it. So we may need an ajax callback to get an available name.

qbnflaco’s picture

I did something similiar to this for the content type for. Human-readable gets converted to machine-readable via jQuery and gets pre-filled. If you tab to the next field you can still change it. Take a look at this patch for the js file.

#227052: DROP: when the user adds a content type, base the type on the name using javascript

lilou’s picture

scor’s picture

Not completely sure I understand the example, but the machine readable name must be editable.

@KarenS: I totally agree, but for a total Drupal/CMS newbie, having to fill in twice the more or less same field does not make much sense. The machine readable field can be in that case guessed and hidden, but still viewable for however wants to. I most cases the machine readable will be the_name_of_my_field, so can be easily generated (see #2).
I found myself explaining why we have a machine readable field to non IT students last week, and it's simply not relevant when all you want is to add field and don't care how the systems handles it behind the scene.

karens’s picture

The machine readable name cannot be changed later because it is used in table names and all over the place. That means the only time you can edit is when it is created. If you hide it then and try to 'guess' a name that doesn't work, you will never have another chance to edit it.

This change was made for lots of valid reasons -- people who use non-ASCII languages where the name the system 'guessed' was unusable because of what happened to non-ASCII characters, people who unexpectedly found they had created a field_date_0 when they wanted field_date (because there already was a field_date), and they would have given it another name if they knew it was going to do that. There are lots and lots of other examples of people who have posted issues about why the name the system created for them was not the one they wanted or was not a useable name. We used to auto-create the names and we had dozens of issues complaining about the name the system created. It was definitely a problem that had to be addressed.

The only possible solution is to let people create their own names at the time the field is created. Which is also what the node module does for creating content type names, so it shouldn't be all that odd an idea.

So we can't just auto-create it. The auto-complete suggestion is fine, so long as it can be edited, but you still will have two fields.

scor’s picture

The auto-complete suggestion is fine, so long as it can be edited, but you still will have two fields.

I agree on that and I never suggested removing the machine readable field. The point I wanted to make is more about the usability for non techies (rather than the way the module is designed). you have really good point re the non-ASCII languages.

karens’s picture

Well, you said

the machine readable field can be in that case guessed and hidden

which means it cannot be edited, so that was my point, you have to make it available so it can be edited.

I understand that there are some people who don't want or need to see this, but I don't see any way to both 'guess and hide it' and also make it editable.

scor’s picture

right. I should have said something along the lines of "guessed, hidden in a collapsed field by default but easily editable". sorry for the confusion. #227052 and #302054 are quite advanced in that direction already.

karens’s picture

If someone makes the autocomplete code into a patch, I'd be glad to look at it.