Unless you’ve been living under a rock you are probably aware of the massive UI change introduced in DNN 9 with the arrival of the so-called Personabar. And you’re probably also aware of the arrival of a new extension to the Personabar called Prompt. In this blog post I will try to shine some light on how they relate and what the combined potential means for DNN.

The Personabar

Since the very beginning of DNN we’ve had a bar at the top of our screen called the Controlbar that allowed editors to reach certain functions. This combined several aspects. It allowed you to:

• switch the page to edit/layout modes
• add modules to the page
• reach common useful functions like clearing the cache (in later versions)
• access the current page’s settings like permissions
• access the admin and host functions

The latter was something of a hack in that the admin and host functions were technically just pages stacked in a dual hierarchy: one for admins and one for host users. These pages would then be hidden from the main page menu and only shown on the control bar. I’ve always found it a bit hacky but the advantages far outweighed that. Now you could add pages to the admin and host menus and essentially the management system became extensible that way.

There were two forces, however, that have exerted great force on the control bar over the past few years:

• the desire to move away from Web Forms towards more modern web technologies
• the fact that several modules were “showing their age”

Ultimately, DNN Corp decided to port their “Personabar” technology that they had developed for their commercial Evoq product to the base platform. I’m not someone who keeps a close watch on what is happening in Evoq but I understood that DNN Corp had long ago acknowledged the above points and had developed an alternative approach to the control bar. And it makes sense to harmonize the products so you don’t spend time on outdated tech when you already have new tech to replace it.

So DNN 9 brought us the Personabar. A left-of-screen grey bar that held icons (text at first) to manage your DNN. But very quickly criticism grew of this new approach. Notably because functions that used to be there in the old admin interface were no longer there. So to understand the full depth of this change you need to realize that nothing could be reused from the old control bar in the new persona bar. The Personabar is a complete rewrite of all the admin functions of DNN. And DNN Corp acknowledged that they couldn’t get 100% coverage of old to new. This was further compounded by the fact that the entire UI was redesigned as well. It wasn’t just redoing the old modules (Web Forms) in new technology (React). The ambition level was much higher. And unsurprisingly this change left users looking for functions that they knew how to find in DNN 8 but could no longer find in DNN 9.

Prompt

I’m going to segue to something else now which was happening in parallel. About a year ago as I was preparing my trip to DNN Summit 2017, I got in touch with my good friend Kelly Ford who lives in Arizona. He hadn’t made up his mind yet about going to the conference and I wanted to make sure I was going to see him. Either he was going to come to the conference or I was going to fly out to see him. He told me he had been working on something he called “Prompt”. And if I’d like to have a look and see if there was some viable business model behind this. Yes, of course. As he was demoing what is now essentially the same thing you get in DNN 9.2 I grew very enthusiastic. I had had similar ideas for a way to script common functions in DNN but remotely but never gotten round to doing something with that. This was a big step in that direction and Kelly being Kelly this looked fantastic and ready to ship.

As we were kicking this thing around between ourselves we kept on coming back to the fact that this should be in the DNN Platform by default. Not some paid for module through the DNN Store. We’re both commercial module developers so we know the market a little bit and we figured that we (or to be more precise Kelly) could not reach critical mass trying to convince everyone to buy this. Having a longer track record in the community side of DNN I offered to help pulling this out in the open and focus on getting traction first. Maybe business opportunities will arise down the road from this, but right now DNN needs this. On that point we were in total and complete agreement. This would set DNN apart from its competitors.

Kelly registered for the conference and we made sure Prompt got some airtime there. We also began our conversations (by this time I had committed to help wherever I could) with DNN Corp about this. Ash Prasad, Will Morgenweck and Joe Brinkman were immediately on board. Yes, let’s do this. By this time I had rewritten the module as a Personabar extension (I was giving a presentation at the event on how to create an extension of the Personabar so I was just combining stuff I was working on anyway). I remember that during my presentation I used Prompt to quickly add a page to the site and a quick gasp in the audience “what’s *that*?”.

Oh, and I ended up flying to him after the conference anyway so we could hang out and work on Prompt a bit more. And besides, who doesn’t want to go to Arizona in the winter?

nvQuickSite

At the conference we also got Clint Patterson and David Poindexter on board as promotors of Prompt. David, you may know, created a DNN installer called nvQuickSite. This is a GUI installer for DNN to be used locally on your web server. It’s a no brainer once you are familiar with it. Of course DNN needs a GUI installer. And David made this.

But I felt it had even more potential if it supported scripting and remote access. I had had some chats with David about this. Ideally nvQuicksite would break into two components. A library that would allow you to script installs of DNN and allow you to use external servers (e.g. Azure but also your own server) and secondly a GUI front end to this. Also it shouldn’t limit itself to just the core, but ultimately allow you to script installing extensions, adding pages etc etc.

This would completely bypass something else we had been contemplating with DNN Connect: hosting DNN “distributions”. Distributions would mimic the Linux world where we’d have much more power and freedom to create DNN editions that the community felt presented a great CMS experience. Or maybe targeted distros like the one we use for organizing a conference. Distros are a great concept and I think we should encourage this train of thought. But nvQuickSite + underlying scripting engine would allow this without having to host large zip files, be caught in version hell and have better upgrade control.

DNN 9.2

Fast forward to the DNN Connect event of 2017 and David Poindexter presents at the event Prompt and nvQuickSite. By this time we are already in close cooperation with DNN Corp who’ve prioritized this for DNN 9.2. Interestingly enough one of their motivations was to implement some more obscure DNN admin functions as Prompt commands. Now the pieces of the puzzle are falling into place for me. I clearly saw a huge win for the community with DNN Prompt but I was wary that DNN Corp might just not care too much about it because it wasn’t something for their Evoq audience. But this changed when I realized we could solve at least some issues with the Personabar using Prompt.

For a long time some have argued that due to “feature bloat” we should have a DNN “light admin” and a “pro admin” UI. There are admin pages in DNN 8 that contain a myriad of options for the end user and the fear is that this scares first time users. Are all these settings important? Do I need to learn all of this? What happens if I click here? I’m sure you get the picture what happens next. Many have come back because they’ve used some obscure feature almost no one uses and we’re left debugging some quirk in the platform.

Prompt could play an important part in resolving this. It would save us time implementing and maintaining very complex UIs in favor of commands we can look up. This is very similar to how Operating Systems work. And I’ve always felt DNN was my “web operating system” (modules being the “programs”). In your OS some functions have no UI and can only be accessed using a command line. It is then open to anyone to develop a UI for it themselves, but the base platform doesn’t include this itself.

Scripting

This post is longer that I thought it would be, but I realize there are many pieces to this puzzle. The puzzle that will reveal a vision on the future of DNN. So bear with me as we discuss this last bit: scripting.

For years I’ve been transitioning my work to more modern web tooling. I’ve always had a love/hate relationship with Visual Studio since I found out it totally mangled my HTML when I switched to “design” in Web Forms and since they bloody well cut the project extension that was essential for doing module development (Visual Studio 2005 if memory serves me correctly) and hastily brought it back as a separate install. I never felt they supported module development well. And as Visual Studio has quietly gone down the path of developing Azure applications, most web developers are using a completely different toolset.

So today I find myself using Node Js and text-based editors more and more. It’s not perfect but there is a lot to like. Notably I’ve grown used to using a command shell during my work. In the Node Js world there are no GUIs. In Git there is nowadays, but at first it was also mostly command line based. The point I’m trying to make is that it feels like we’ve come full circle. From the days of DOS where everything was scripted, through the days of “wow” Windows where we had GUIs for everything, back to the command line because “hang on, this is way faster”. Or “I’m developing RSI from all the clicking”.

As I had grown more accustomed to doing stuff through a command line I kept wondering how it would be to be able to do the same to DNN. And whether this could convince some of those other script addicts I was watching doing web development on Youtube, to use our beloved platform. Imagine having “add-page My New Page”. Or “Authorize-User peterdonker”. Or … “dnnpm install modulex”. Now *that* would be a game changer. Right?

You’re now probably seeing how all this fits together. Recently I was prompted (no pun intended) by Andrew Hoefling to begin work on a “remote scripting possibility” for DNN. He first wanted to start work on something local on the server, but given that Prompt works through the WebAPI there is no reason to limit yourself to the machine. Using JWT you can safely access the WebAPI and you could run any command that Prompt can run remotely. I quickly made a proof of concept for this and lo and behold it works. This has now blossomed into a new project where you can run DNN’s Prompt commands from Powershell. Yes, you heard that correctly: Powershell. That was the last piece of this puzzle. Why invent your own scripting engine when your PC already has one? Powershell can be extended as you know and we are now building a Powershell module that will allow you to remotely script DNN through Prompt!

What next?

Hopefully you’re seeing the big picture now. So what’s next for these pieces. In my humble opinion we need to do the following:

• Begin creating a powerful command set in DNN. What we have now is great, but it’s just the beginning. We can also develop commands in a community library.
• An extension of the above: implement a list of missing functions from the DNN 9 UI in Prompt
• Finish the Powershell component and release that
• Help/convince David to separate the front end GUI of his nvQuickSite and build it on top of the Powershell engine using prebaked scripts
• Then create a common repository for those scripts so we can share “distros”

Let me know what you think. On Facebook in the DNN Connect group or on Twitter @pdonker.