New Features would go in J4.

Example 1

Each page needs it's own 'Hero' area consisting of an image and overlaid text. This cannot be hard-coded into a template.

Currently the only way to provide an interface for managing the 'hero' area is to create module for each page. This isn't ideal for the reasons outlined above.
A better solution would be to specify the hero image as part of the Menu Item itself.

This is exactly what the plugin events in the MVC layer for forms is meant for. In a well designed and documented system, a plugin could add fields to the form using the existing API (something that isn't well documented, custom fields make this a little easier but they don't handle the upload aspect of this example) and have them easily rendered (this is the part that's most painful as far as UI goes since most forms in core don't use the API to dynamically render fieldsets). Truthfully, some of these plugin events probably belong moreso in the Form API than the MVC classes but that's a debate for another time, but the point is with some reverse engineering you can pull this specific example off today.

Example 2

There are different areas of the site that need their own 'theme' colours.
Specifying this colour (or selecting a theme) should done as part of creating a new Menu Item.

There is currently no way to specify this sort of thing anywhere in Joomla.
Adding custom fields would allow for this.

You can do this with the existing template styles functionality. A template style is just a set of parameters to use when rendering a template, you can have multiple styles for one template. The advantage here is you then manage that style group in one spot instead of potentially multiple menu items.

Example 3

Each area of the site (or each page) should be assigned to a specific user who should act as the main point of contact for that page. It could be their responsibility to keep that content fresh, for example.

Currently there's no way in Joomla to specify this.

This sounds like ACL to me. Or maybe a custom field would help with adding a note about this assignment, but it still wouldn't render anywhere useful outside of the edit screen. On a semi-related tangent, I've been doing some WordPress work for one of our company clients the last few weeks, and it was refreshing how easy it was to add data anywhere in the admin UI (whereas with Joomla you're hijacking onAfterRender in some cases to add data, and heaven forbid you do something to customize the component list views), and I'm now sad that the JGrid class never got embraced and is gone from 4.0. There's still way too much of Joomla that lacks real extension points for developers to do anything useful for end users.

Hey, thanks for the replies, much appreciated.
Not sure if I fully understand/agree with all the points though.

@mbabker :

Example 1:
"they don't handle the upload aspect of this example" - you mean uploading the hero image? I'd use the media custom field for that - it allows you to upload images. Did I misunderstand what you meant?
Custom Fields in this example would be quicker and easier than developing a plugin.

Example 2:
Perhaps not the best example - but in my case template styles aren't something I'd want my admins having to fiddle with - in my specific case I could end up with 40-50 template styles with a lot of duplication.
What I'm talking about really assign a category/brand/theme (call it what you will) to a page.
Without getting bogged down with my specific scenario, think of it like needing to apply a 'badge' or 'tag' to specific URLS. (Note I could possibly have used Joomla tags here but they're not available in this context either).
A custom field list of some sort would solve this problem easily.

Example 3;
"still wouldn't render anywhere useful outside of the edit screen" - not necessarily. Though not my use-case, there's no reason you wouldn't want this point of contact appearing somewhere on a page., visible to users.
Also, it would allow, for example, a custom component to provide users with a list of pages they're responsible for.

I guess what I'm saying boils down to - there are at least these 3 examples of where adding data to a Menu Item would be very useful (at least to me) and custom fields seem like the obvious choice.
As I mentioned before, the precedent is set with the Page Display fields - there just isn't enough of them.

If necessary, I could probably provide more use-cases in due course.

Thanks

"they don't handle the upload aspect of this example" - you mean uploading the hero image? I'd use the media custom field for that - it allows you to upload images. Did I misunderstand what you meant?

If that media field is a wrapper around the same media field used in core where it lets you upload images into the modal, then that works. But out-of-the-box no custom field is able to process uploads on its own (that one hooks into the existing logic in com_media), as a generic re-usable field can't make assumptions on how to safely process uploads; so if you're looking for anything that supports uploads beyond that field's capabilities you're still writing your own code.

That second example is the exact use case for template styles or use of a page builder component, both of which already exist. Custom fields for this specific scenario in all honesty is still going to call for you to write a plugin that can parse that field data and convert it into an inline <style> element for basic CSS changes (similar to the options for the backend template now), and higher level layout changes are going to call for appropriate page layouts using the capabilities already in core or one really hacky default.php layout with way too many conditionals.

Your first and third examples are the exact use cases for the developer oriented plugin approach for adding fields to forms. The only difference between custom fields and the plugin approach is one requires you to have PHP knowledge and the other one doesn't. And with that third example specifically, the whole "Also, it would allow, for example, a custom component to provide users with a list of pages they're responsible for." bit, that just further solidifies that you really should be integrating a proper plugin writing data to a proper database table and not "hijacking" the #__fields and #__fields_values tables to store something that realistically belongs in a pivot table with proper relational schema.

While custom fields might seem like the "easy" way to go about it, in all honesty I would suggest that given Joomla's architecture they aren't going to fit in with your desired workflow that easily. In fact, it runs into the same problem modules have pretty easily (the whole "I want a module to show up on this category menu item page but not on the article pages that inherit from it" scenario that you realistically can only address with plugins or hacks in your template).

Thanks.

The media custom field would work just fine in the scenario described.

Custom fields defined for a Menu Item in this case would be retrieved and acted upon by the template itself, no extra plugin would be required.

I've no problem with writing plugins, I just thought it might be useful to share my experience and thoughts on occasions where I'd find it useful / convenient to have custom fields on menu items.
No worries.

Cheers

I am not sure if you are talking about a solution without coding or not. If you are willing to code, you can add custom fields to menu item types easily in the view/tmpl/default.xml file. Then change your default.php file to generate your html code depending on that field.

Please disregard my comment above. I now realize you are talking about custom fields that can be defined in the browser interface.

@muesliflyer thanks for taking the time. Yes, I was just trying to present some use-cases for including the custom fields options to menu items.

In the end I made a plugin (as @mbabker suggested) though I still believe it would have been more convenient to have had custom fields.

I'm going to close this now.

Thanks,
Andy