Missing fieldtype documentation: 6 fieldtypes

[Peer]

The framework documentation at this url:
https://frappeframework.com/docs/user/en/basics/doctypes/fieldtypes
provides descriptions for 37 fieldtypes:
Data
Link
Dynamic Link
Check
Select
Table
Attach
Attach Image
Text Editor
Date
Date and Time
Barcode
Button
Code
Color
Column Break
Currency
Float
Geolocation
HTML
Image
Int (Integer)
Small Text
Long Text
Text
Markdown Editor
Password
Percent
Rating
Read Only
Section Break
Tab Break
Signature
Table MultiSelect
Time
Duration
JSON

But there is no documentation for the following 6 fieldtypes:

Autocomplete
Fold
Heading
HTML Editor
Icon
Phone

These can easily be found when opening /app/doctype/DocField on an installation, then check the “Options” of the field “Type” where they are listed.

So what are the ins and outs of these? Guessing only gets users so far. For instance: Does the Phone field provide mechanisms for verifications according to country prefixes, mobile numbers? Are there provisions for linking to phone infrastructure hardware? Etc. What’s the purpose of autocomplete? Duh, autocomplte. Of course. But then, there is autocomplete functionality in Link fields already. So what’s the matter with autocomplete field type?
And so on
Undocumented => guessing => getting lost in ambiguity of creative mind.

[Jeel]

@Peer for autocomplete check this Autocomplete field property exmaple needed if any?
For fold you can check this Fixing Long Forms | Frappe Blog
Icon fieldtype is used in workspace.
Heading field is shown in image.

[Peer]

Revisiting this topic, a bot now asks me this:

“Has your question been answered?
Highlight the answer and help others by using the solution button below the correct reply.”

Well, it’s about a “missing documentation” bug.

It’s still not in the documentation which has still a “one year ago” changed date.

I don’t count a random question on a forum, triggered by someone (me) who happened upon a missing bit of info – and suspects more missing ones, then looks a bit closer and finds these other ones, and thus tries to get to the bottom of the more general issue – and the answers in the forum: useful but which should be in the documentation, as a solution.

If at least a link to this thread would appear in the documentation!
Unless the info is at the place where anybody turning to the docs to get informed about the software, would expect it, I don’t consider the issue to be solved. Take that, bot!

Unlike the Erpnext documentation which has kind of a “suggest improvements” form at the bottom of the pages, the Framework documentation unfortunately does not.

It could help speeding up improving the doc, though, at least that’s what I think.

Although I’m not sure if the inputs to the form are used by someone, I just didn’t check.
Do I need to? Who knows what that would uncover.

Taken a contrario, a form for feedback at the Framework’s doc might help calming people for the while it takes to actually use the feedback, or them to get upset, kind of like it happened with translation suggestions.

Maybe, after all, getting the doc right, and into the doc heap, at the time a feature is created, would generate less additional work than herding everybody to help scatter questions and answer bits information around everywhere in forum, blogs and whatnot and then consolidating the mass of chaos+infobits later, when it got hard to actually do this.

Just my 2ct.