Do you still mark prefilled input fields as required?

Question

I'm creating a form in which a user downloads an analytics report. There are multiple fields that are technically required for submission, but we prefill certain fields so that it's less work for users. Here's a sketch:

More examples:

Report Name: [Monthly Report]

^ We would prefill the input with a name, but users can also edit that name

Send Date: [01/01/15]

^ We allow ability to schedule the report and prefill with today's date, but they could also edit it.

Should these fields still be marked as required?

EDIT:

Thanks for the comments below. I realized I was a little unclear in the definition of the input. It's not an example of what should be placed in the input. It's real content that would be used. So more like a default: http://designinginterfaces.com/firstedition/index.php?page=Good_Defaults

While the examples in that article are from local applications, I wondered if the same rules apply to web app?


ANOTHER EDIT:

I've found some other examples/variations. Perhaps someone could speak to those or at least let me know what the term for these scenarios are. Or even if this is the better route to go?

Editable fields:

Noticed that in JIRA, when you hover over content it is editable, but otherwise the default is not editable. But how do you teach people that those areas are editable? I think Squarespace does this too. http://screencast.com/t/Z2EvPiAN

Showing the preselected input as not editable, but asking for confirmation:

Answer 1

Those are still required fields.

Based on your edit, your watermarking is using actual data, so you need to signify what fields are required.

The From field you obviously need them to fill in, so you can't accept the default.

The Report Name, Subject, and Date Range fields, however, that's your call. They are valid defaults that the user may want to leave as is. I think that is up to you or maybe some A/B testing.

I would still mark them as required fields though (it's just that the requirement has been met).

Answer 2

While it depends on the form and the data, in your particular case I wouldn't do it. If you pre-fill fields, most users will leave them "as is" because they won't know if they can modify those fields, or they won't care. Either way, a bad behavior because neither you nor the user will get the expected results.

Pre-filled forms should only be used when the input is preferred (for example, pre-selected price options you want the user to choose) or when the form is so long some help may be appreciated. And in any case, it should be very clear they can modify the information. Keep in mind you can always have non-modifiable data as part of your form, but it wouldn't look as a form input anyways

Answer 3

Some really good answers here and they pretty much nail down the situation. To throw my two cents in, I would say that the more you can do to reduce ambiguity, the better. Prepopulating the fields is a great convenience for the user, but I think that there is still a need to give them a clear indicator of what is expected of them if they decide to interact with the data. I like the idea of field description notes as mentioned above, but a little red star goes a long way on it's own. I guess my litmus test would be what would the user expect if the form wasn't prepopulated; if the mechanism that populates the form was broken for some reason, perhaps. They would definitely need some sort of extra indicator then.