Articulate Concepts & Ideas

[YodasMyDad]

Hey, As per the Twitter DM, I'm going to dump some stuff here for you. I've been pondering why we (.Net) don't have a decent WordPress alternative. One that is built around a simple .NET pluggable architecture, I'm currently playing with concepts for that using RCL's & Razor Components.

Part of the messing around with this made me think about Articulate, and how it would be nice to have something in Umbraco. I'll lay out my thoughts and concerns below and let you tell me your thoughts on each bit.

Why?

As I have tweeted about recently, Umbraco's issue is that it's really created for devs (Mid to high level to begin with) and the vast majority of packages are dev utilities or other things to help devs create the sites for the end user.

And packages, like Articulate for the end user, are not easily extendable (No plugin architecture), and lack a lot of features that even a basic equivalent on say WordPress would have (Not a dig at you, you've put in a ton of work).

Thinking of something super simple. Let's say I want to add a newsletter signup form that goes straight into something like Convert Kit. Where I want to be able to add to the content of my blog where I choose, but also put it in the footer or even on a sidebar.

To achieve something like this, thinking off the top of my head, I'd have to create a Macro, so the user could insert it via a Macro picker in the content, then I would need to go to the source code for the Theme I'm using, figure out how to add the signup form where I want it, submit a PR and you (or whoever) would say that it's not needed for anyone else.

Then I'd need to fork Articulate, make my changes, publish or push my own code and now I'm out of sync with the main product. You get where I'm going with this. This is the same issue with ALL end-user packages in Umbraco.

With HQ purchasing Vendr & Konstrukt, I'm hoping this is the start of something new where they have finally seen the issue here, which alienates a HUGE amount of mid-level devs and hobbyists.

Concepts/Ideas

I think to make people want to get more involved with Articulate, make themes etc... there needs to be a way to encourage plugins. The ideas below are just things I'd like to do, some I already have played with, others not, as I'm a mid-level dev at best, and I need someone like yourself to help with architecture/give feedback.

Block List Editor (Editor Plugins)

1. Move from the RTE/Markdown Editor to the Block List Editor, and create a suite of starter Block items. Which would include an RTE Editor, Markdown Editor, Image Gallery, Image Carousel and others to be agreed upon.
2. Each Block would inherit from a default editor plugin composition that included some default settings/options. One would be a checkbox with something like 'Use Razor Component'. Then for people creating their own blocks, they can package them up using this as the base inherited composition for their blocks.
3. The default way to render the Blocks will be via View Component, and as above the ability to use a Razor Component if you wanted. I have created a personal blog that uses this method and it makes it easy for people to package up things like View Components/Razor Components in Razor Class Libraries (RCL's) with assets and you could install via a Nuget package (Which I think would be the default way users add Editor/Content plugins in).
4. How to get the data into Umbraco for new Blocks/DataTypes? Not sure on this, but see USync below. Need some ideas/input for this. Must be as easy as possible.

Content Plugins

The reason for two different types of plugins, is so we can have something similar to @section on Razor, but our own plugin implementation. Like Actions in Wordpress.

Content Plugins would be Razor Components (Packaged via RCL's as above) which are rendered into the theme layouts/templates/post.

Again, I have a POC I was playing with, that enables RCL's added through Nuget/Reference, then using some custom plugin reflection code (Taken from [ExtCore](https://github.com/ExtCore/ExtCore)), just grabs all plugins by a specific type/interface and then you can render on demand, because you can include css/js in the wwwroot of RCL's, you automatically know the path to the assets and can include them in the page. You can see here me asking about this on SO, when I was [developing my own POC](https://stackoverflow.com/questions/75867688/using-reflection-how-do-i-list-the-contents-of-the-wwwroot-files-in-a-razor-clas/75875660#75875660).

The issue is how to render them in different places...

This is where I got to with my own POC, and was thinking about something like, all plugins get found at startup, and put into various dictionaries in memory based on the section/place (Not sure of the name) they would be rendered.

Then scattered around all themes/templates there would be a default list of these sections/places where they are called via a name, and some default data is passed in (i.e. Theme name, maybe user's info if logged in). Something like

@RenderContentPlugin("TopHeader", new { Theme: SomeNAme, Data: Object })
@RenderContentPlugin("BeforePost", new { Theme: SomeNAme, Data: Object })
@RenderContentPlugin("InPost", new { Theme: SomeNAme, Data: { RowNumber: 3 } })

The assets would also be grabbed like that StackOverflow post link above, sorted and filtered (Duplicates, two plugins linking to the same outside JS CDN library or whatever) and then rendered in the header and footer.

This means the plugins rendered can be static, Blazor WASM, Blazor Server, Web Components, JS driven, or whatever, this is the great thing about using RCLs and Razor Components.

Again, I'm just a mid-level dev, not an architect, I have a concept,

Usync

Just a thought. We could include Usync within the package. This would be a great way / an option to get the custom Blocks/Plugins over into Articulate.

It's free and seems to have a file-based approach to the import/export. If there is a way for people to easily export their data and include it into the plugin RCL, which they could then easily import it into their own sites.

I don't know. Just me pondering.

Konstrukt

Again. Would be great if we had this built in as a package (If the HQ make it part of the core, which they are crazy if they don't).

Then could have an Articulate section, built-in Konstrukt, that people can easily add trees and dashboards to with .Net code.

Have some middleware extensions that look for a specific interface in their plugins, then loads that into the Konstrukt builder, so people can add much more complex plugins, without having to touch the Articulate source code, or have to know a ton of custom/advanced JS, which I know from my own experience, and speaking to other devs, puts them off.

Concerns

1. New back office. Doing any work before that is out, would potentially require lots of extra changes
2. Your time. Again, if you like the ideas, I would definitely give it my best go to move forward but would need a fair bit of advice and guidance
3. Documentation. Again, just need to have really, really easy-to-understand documentation, something which I could again, try but I'm not the best at this stuff
4. HQ taking Articulate in-house without warning when attempting to do this stuff

In Summary

There needs to be a super easy, .Net-driven, pluggable way to extend Articulate and allow for more creative content to be added to the blogs. Something that allows the hobbyist and mid to low-level .Net Devs easily create and share plugins for other people to use.

[Shazwazza]

Thanks for putting this together. I'm not opposed to many ideas here but your concerns are all valid (though I don't know anything about HQ taking Articulate in house).

I'll comment below on a few things above and then add some additional thoughts below:

Move from the RTE/Markdown Editor to the Block List Editor, and create a suite of starter Block items. Which would include an RTE Editor, Markdown Editor, Image Gallery, Image Carousel and others to be agreed upon.

It would be OK to add a new type of archive type based on the block list editor but There are reasons to have and maintain the 2 default types:

• Rich Text - It's simple and is used for folks that wish to use Live Writer
• Markdown - It's simple and is used for folks that like MD and is used by Articulate's simple post creator

I'm sure with some sort of options these could be customized to populate blocks on a new archive type but I don't see a reason to remove these.

Thinking of something super simple. Let's say I want to add a newsletter signup form that goes straight into something like Convert Kit. Where I want to be able to add to the content of my blog where I choose, but also put it in the footer or even on a sidebar.
To achieve something like this, thinking off the top of my head, I'd have to create a Macro, so the user could insert it via a Macro picker in the content, then I would need to go to the source code for the Theme I'm using, figure out how to add the signup form where I want it, submit a PR and you (or whoever) would say that it's not needed for anyone else.
Then I'd need to fork Articulate, make my changes, publish or push my own code and now I'm out of sync with the main product. You get where I'm going with this. This is the same issue with ALL end-user packages in Umbraco.

This would be possible today without doing any of the above. It is possible to modify the current Articulate archive types. You could add additional properties to them and just render these properties out in your own View based on your own theme files. Articulate 5 doesn't allow you to modify the built in themes. If you want to modify a theme, you just create your own theme in the back office based on an existing theme. These files are then stored in /Views/Articulate/{YourTheme}.

You can add a block list editor to Articulate now and render that out in your view however you want using the underlying IPublishedContent model. But there isn't enough flexibility to start removing built in properties because these are referenced in quite a few places. For example:

• Strongly typed Articulate models like PostModel
• BlobMl import and export
• Disqus XML exporter
• Articulate default searcher
• Content saving handler - to populate things like excerpt

There would need to be a way to make all of that more flexible with custom editors. But instead, I'd recommend to just add a new type of archive node just based on the block list editor and then update all of the above to look for that property name (i.e. postBlocks).

I think before considering any sort of 'Plugin' system, the first step would be to create this new block list editor-based archive node type and wire that all up so that it works with all themes.

From there, any plugin system would need to be well defined, but we'd need to really think about what Umbraco already offers as far as block list editor plugins vs what is missing from that architecture that wouldn't already fulfil a plugin for Articulate.

[christianguitarfreak]

I'm interested in using Articulate for our Umbraco website. We're currently on Umbraco 8 and will be updating to make sure we're not on End of Life. Can you please send me some links of some websites that are currently using Articulate for blogs?

[Shazwazza]

@christianguitarfreak I can't really know who uses Articulate, there's not metrics or anything emitted from the library. My site is though: https://shazwazza.com

[christianguitarfreak]

Shannon, This is amazing. How hard would it be to add LinkedIn for a way for users to react (perhaps even instead of Facebook) if we spun this up on our website? Bryan Lloyd Senior Digital Marketing Strategist

[Shazwazza]

@christianguitarfreak Articulate works with themes which are just razor views. So you can copy/create a theme and customize it however you like.