Rename content apps

[TimGeyssens]

Since the introduction of content apps in v8 they are now also avialable on other types (like doc types, member types, ...)

So to just name them content apps seems a bit odd..

For now I would name them context apps (maybe someone has a better idea?)

This isn't the sexiest issue, but if we keep it backwards compatible the content apps name will just fade out... (so also update the docs of course)

[nathanwoulfe]

Hi @TimGeyssens, I tend to agree - when content apps were only on content the name made sense. As you said, now that they're available on other types, the name misses the mark.

I've labelled this as requiring HQ discussion, since it's more of a product decision than something to be resolved via a community PR, but no reason why the conversation can't continue here too - would be good to see some alternative naming ideas, which might help make a change easier for HQ to justify.

I'm not sold on context apps, probably because it's so similar to content apps. I'd go for plain old 'apps', but that then conflicts with the Umbraco Apps concept, which may or may not be an issue.

[TimGeyssens]

Thanks! Yeah doesn't have to be context apps...just something that covers the whole thing

[filipbech]

I think you both bring up good points, and we would love for community-ideas on naming this. (and other parts that you find is mis-named - but lets keep this issue to contentApps)...
So keep the discussion going - no timeline or promises from HQ, but we do really want your feedback and ideas!

[soreng]

I think the naming was done based on the view that is being worked on, in umbraco. When ever we look at doctype, media, content etc, we always load a piece of content that we can interact with, through content apps.

The naming makes sense for me, since I see it as above, but a more generic name, that won't cause overlap with sections or other objects in umbraco that already exists.

Calling them "apps" will cause people to think they can do more. They may be need to be called "editor apps", since they relate to editing an entity.

[abjerner]

When the content apps were introduced, HQ emphasized that these were read only (eg. on content, switching to a content app also hides the save button). I've never really fully understood this part, as I think there are valid scenarios where a content app might write some content or settings.

The read only part makes a lot of sense for content apps like my Skybrud.Social.Google.Analytics package, but for instance, in Skybrud.Umbraco.Redirects, Tim and others suggested a content app for editing redirects (opposed to a property editor as it is now). I think this makes sense, but the content app then wouldn't be readonly.

Re-defining what a content app is, and what it's purpose is, might help us come up with a better name. Since the view for editing content, a media or similar is referred to as an editor, I think the term editor apps as suggested by @soreng makes a lot of sense - as least from a developers perspective.

---

And if we were to re-define or extend what a content app is, I'd like to see the following:

• In Angular, a content app would be able to save some additional data on the overall "object" being edited

• Umbraco will introduce a new event in C# so developers can expose this data when Angular fetches "object" from the API, and another C# event for picking this additional data up when Angular sends "object" back to the C# API.

As content types now can have content apps as well, a scenario could be to save some extra settings for a content type which I as a developer then could use when rendering content of that type on the website.

I know this is slightly going off-topic, but understanding what content apps currently are, and what they could be used for going forward, could help finding a better name.

[TimGeyssens]

ok sounds good :) editor apps, but since they are also available on doc types... that is not something an editor will see... or is an admin also an editor? Maybe user apps?

[abjerner]

@TimGeyssens my point was that the overall Angular components for editing these different types are also called editors - not to be compared with the backoffice users. I know this can lead to some confusion and ambiguity, but IMO it's the best new name I've seen so far.

[TimGeyssens]

ok makes sense, thanks for the extra info :)

[soreng]

The name was not based on being a user role, but rather the action being executed. Editing is what the (current) apps extend. The info “tab” is an app, the “content” tab is an app etc.

…

On 12 Sep 2020, at 21.25, Tim Geyssens ***@***.***> wrote:  ok sounds good :) editor apps, but since they are also available on doc types... that is not something an editor will see... or is an admin also an editor? Maybe user apps? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[nathanwoulfe]

Editor Apps sounds pretty good to me - user is editing something, be it content, a template, content type etc.

[dawoe]

I vote for context apps.... you are editing data in the context of content, media, member, ....

[nathanwoulfe]

Experiential Contextual Assistive Editor Applications. ECAEP, which just so happens to be PEACE backwards.

[dawoe]

Can't argue with that one.

[soreng]

Experiential Contextual Assistive Editor Applications.

ECAEA?