Blog

In DNN 5.0 the artificial differences between Regular and Admin pages was removed. All Modules showed in the Admin-Menu can now also be placed on any custom page and basically everyone could use them. This article gives you instructions how to allow Non-Admins to access the DNN Page Management and workaround some limitations.

Erik Van Ballegoij already wrote about how to give non admins access to any admin page. You can just insert the module like any other to a desired Page. It’s important to give the desired user(s) Edit Permission on that Page (not just on that module) otherwise they get an “Access Denied” warning.

Basically that’s it. Users can now edit Page settings for Pages they have edit Permissions to but for no other Pages. There are just two limitations:

Drag and drop to reorder Pages only works for Administrators

Add Page(s) only works for Administrators

To get these functionality to work for Non-Administrators adapt the file at ~/DesktopModules/Admin/Tabs/Tabs.ascx.cs. You’d need to comment out a Security check PortalSecurity.IsInRole(PortalSettings.AdministratorRoleName) 3 times:

OnInit: comment out the if-Condition (line ~237) and the else statement (~243-247)

This Blog is about 2 things. On one hand it’s about Syntax-Highlighting, but actually it’s more about creating safe No-Server-Code-Apps.

Part 1: Syntax Highlighting

I recent Blog-Post by Peter Donker called Strong Typing Your Settings on the DNN-Connect inspired me to this. Basically we often want to show a bit of code to help people get something to work, but then…

…the WYSIWYG f***s it up :(.

If you read my post #3 on Responsive/Mobile about The Good Death of WYSIWYG, you’ll know that I’ve had my bad times with the not-so-great WYSIWYG and that I’m glad it will become a relict soon – thanks to responsive websites which cannot „responsively“ handle WYSIWYG content.

So Peter had all these nice code-snippets in his blog, and they looked really nice – thanks to a open-source JS called SyntaxHighlighter. It looked like this:

So I figured: there should be an App for that!
A day later I revisited the blog, and everything had fallen apart. It looked like this:

So I figured: there should REALLY be an App for that! My guess was that someone re-edited the blog in the WYSIWYG, and BAM! the code was mangled. Had happened to me a lot already :(.

Part 2: Safe No-Server-Code-Apps

I’ve made it my mission to promote creating no-server-code-solutions. Wouldn’t it be nice if…

…an installed Apps (modules) couldn’t contain server-code like C#

…and thereby could not crash the server, no matter what

…and could not contain DB-access code to „private“ information?

…and the Apps would not be centralized, but an own install per portal

Because if this were possible, it would allow us to…

…give admins / web-designers the right to install Apps (not possible right now, too much risk)

…give admins / web-designers the right to modify Apps as they need to (without host-permissions)

…modified Apps would not effect other sites!

Enabling this is part of my mission. It’s something that DNN cannot do by itself (for various architecture/feature reasons) but 2sxc can do it! We’re not 100% there yet, but getting closer. And the Syntax-Highlighter App demonstates this – because it can do everything needed without any App-specific server-code. These are some features, that usually require code on the server:

Modification of strings (done in JS)

Selectable Color-Schemes (done with well-selected value-names in the dropdown so you don’t need code)

Selectable programming language causing different systems to run (done with good dropdowns & logic in JS)

Prevent multiple copies of CSS & JS (done using DNN-Resources-Bundling and some JS)

SEO enabled (done using standard HTML)

Editing data-UIs with Multi-Language UIs (done with 2sxc)

Multi-Language output (done with 2sxc)

Data storage, retrieval & versioning (done with 2sxc)

We’ll release a few more such Apps in the coming weeks, and I would love your feedback. Do you also see the need? Do you think we’re wasting our time optimizing for this? Please tell me

Razor is the future for most output-oriented .net stuff. This also applies to WinForms-based CMS like DNN. But fortunately, they got it right and added Razor-Support about 2 years ago. In my opinion, this is something that most people haven’t figured out yet – partially because they can’t find the code-snippets to help them. So here goes: all the ways you could use to access SQL-data directly from Razor without pre-compiling something.
So no Entity-Framework or similar. The five options we’ll review are:

Fastest code: using a simple SQL-Reader

A bit more comfy: using a DataTable

With typed POCOs: using PetaPoco

Nicest: using 2SexyContent DataPipelines (SqlDataSource)

Nicest but with more complexity if needed: using 2SexyContent DataPipelines with manual data (DataTableDataSource)

Hope you liked it…

Remember the old days when we pretended we had What-You-See-Is-What-You-Get? Right now I’m writing this blog on the Telerik-editor built into DNN and it’s terrible.

There are a zillion bugs – like hitting backspace at the beginning of a paragraph will reformat my text (no joke). I had forgotten how bad it is, because we barely use the WYSIWYG nowadays – and you too will soon stop using it. If we’re totally honest with ourselves, it never worked – and now it’s clear that it never will work.

100 Previews

These pictures show the very same content – in 3 of over 100 different previews that would be possible:

The reason is very, very simple: When A4-paper was the final destination of our work at the computer, the goal was to show the resulting paper on the screen – eliminating the guesswork of what we get when we print. So WYSIWYG meant simulating paper on a PC while the editor added content (texts, images, etc.) so that ever move would look like it’s being done on paper. This is simply not possible when creating responsive content – as it will look different everywhere.

Preview would also need to show behavior

Ideally it will not just look but also behave. Something that you can’t See before you Get it. Touch/Click is not the same thing, and forget mouse-over in a mobile device. But even if reduced to layout-behavior – you’re stuck. Let’s just review the options where the image could go when screens vary:

The image could go above the title (which it actually does after a while)

The image could go between title & text (which it also does for a while)

It could go under the text

We could remove it

The size could change

It could become super-tiny with a click to view (not shown)

It could be replaced with an icon with a click to view (not shown)

…or a combination of these (very, very common)

This is impossible to preview, and even harder to configure – especially in a tool that tries to simulate a paper-simulator.

Preview is impossible, Code is absurd

Writing the correct code is even harder. Here’s the code for the bit above, most of the text was removed to make it easier:

And here the annotated version

special classes to ensure correct display-behavior based on various rules/screens

some content inserted more than once

special resizing-parameters

A normal editing person simply cannot do this – and shouldn’t! And the WYSIWYG-Tool can’t handle this – and shouldn’t.

Here a few links from a current project that show some responsive behavior (open the link and try various screen sizes).

Redefining the Mission of the Editing Interface

So let’s redefine the mission of an editing interface to match future needs: We need a UI to add content to a system, in such a way that the system can then present it to the user as best fits the user’s situation (device, capabilities and context). I love bullet points, so let’s just repeat that:

UI for the editor to add content…

…to a Content-Management-System

…so that the Content-Management-System can show the content to a user…

…optimized to the user’s device, capabilities and context

I would love to write more about context, but will reserve that for another blog. What I would like to emphasize is that it’s not the editors responsibility to show the content in a designed fashion but the responsibility of the CMS. A lot of work wasted by the editor is now for the CMS to do.

Show the full text or the intro? Let the system/web designer decide.

Show a large image or just a thumbnail? Let the system/web designer decide.

Image to the right or above the text? Let the system/web designer decide.

Resolution of the image? Let the system/web designer decide.

The content-editor clearly lost many of his responsibilities. The things an editor must do in the future don’t need a WYSIWYG any more. It’s actually important that he doesn’t believe he’s seeing what he gets.

What must an Editor-UI do in the future?

Divide an Conquer: The CMS of today needs information split into it’s smallest parts, so that it can use it as best as possible. The title of an image can never again be mixed in the same „field“ of data (like with a WYSIWYG) because that would limit the CMSs abilities to optimize presentation. This way the CMS will also be able to hide information if appropriate, present it in an overlay or pass the information to another sub-system like an on-device calendar or mapping-tool.

Semantics – understand the Content-Type: The UIs must know what kind of information the editor is adding – to correctly offer him the right fields. Are you adding an image? offer 2-3 fields for that. Add a gallery-item? needs a few more fields. An address? 20 fields.

Choose presentation: Although the editor cannot define how the content is presented (what HTML, CSS, etc.) the editor still wants to control which presentation is used for his content (I want to show the image to the right of my text if possible and not to the left…). The UI must allow the editor to choose this.

Yes, we still need editors for formatted text

…but not because it shows us how the result will look. We need it, because parts of what we write still needs features like emphasis with bold/italic or because we need inline-references (links) to other information. But that’s the entire scope. Many of the things we could do in a WYSIWYG will go away.

These WYSIWYG-features will die

Inline images and all the necessary features for alignment and such

Font-definitions – this always was bad practice, and now it’s really time to go

Tables – also something than barely ever worked – the CMS must „know“ more about what it’s showing, so a WYSIWYG-table is a no-go

Inline videos

HTML-templates (a popular workaround to get some consistent look in the WYSIWYG) – obsolete

Where can we find such editors today?

There is of course the competition – for example, drupal and umbraco are pursuing such an approach. Within the DNN-environment I believe the only real tool for this is 2SexyContent (disclaimer: we created this). You could also do some of this with XMod or Form and List – but it would be a lot of work and not deliver a satisfying user experience. This is actually one of the core reasons we started with 2SexyContent 2 years ago – there just was no other solution for this.

Adapting them – if the code is available – needs visual studio to develop, compile, test, etc.

Much of the development/customizing time is focused on „plumbing“ – getting things done, which a CMS should do for you (but DNN does not do, because it’s not a CMS unless you add 2SexyContent).

All this and more has led us to not even evaluate simple modules as evaluating the modules takes more time than creating it again. This is not the way it should be, but the way it is.

So we decided to change it

Today we released 2SexyContent 6.0 – and it’s a game-changer. And we really wanted to make sure people „get it“. So I created a brand new App in exactly 10 minutes, and recorded myself doing it. In the last few seconds I even packaged it for redistribution. The App is simple, but it contains some very powerful features like

Parent-Child (or List/Details) data and views

Content is multi-lingual

Templates are multi-lingual (using central resources)

App has central settings that apply to all uses

AJAX-Lightboxes for users, „normal“ pages for Google

Versioned data (yes, you can get back the data as it was before)

Unpublished save (add data, but only the editors see it)

…and much more. This HTML-output of the App isn’t production class – for that the HTML would need some more tweaking – but we’re really exited because it just shows how productive things can become, if the „platform“ does everything for you. Watch the real-time video below or try out the App yourself (links below…)

Your core mobile-implementation strategy sets strong restrictions as to what you can do and what not. So before we start tackling each issue (like responsive tables), we must decide what strategy to pursue.

Fortunately, this is very easy: Responsive strategies beat Adaptive strategies in about 99% of all cases. If you’ve been influenced by Microsoft these last 10 years, you may still believe in Adaptive strategies, but even Microsoft seems to find their way, judging by the new presentations of Universal Apps.

Many words like Adaptive & Responsive have been used by various people – and often incorrectly. So I will first explain what most experienced web designers call Adaptive and Responsive.

…just about every new website or online store with a reasonable budget – just do a quick search, you’ll find thousands of great, inspiring samples

Why is Responsive so much better?

There are actually many reasons, but instead of going philosophical – which just causes many arguments to be exchanged – let’s look at the 2 decisive factors today:

Everybody who actually tries doing adaptive will quickly discover (for reasons mentioned later) that it’s not possible to do adaptive, without responsive. So if you start with adaptive, you end up doing both. But it’s easy to do responsive without adaptive, so you might as well just simplify.

Responsive has already won the show – research it in Google and similar, it’s a clear cut case. Even if you liked adaptive, must must admit it’s over. Here’s a Google trends-chart from today

So those were the dry facts. You might wonder why Adaptive failed. There are many reasons, here just a few:

Adaptive only works with client databases (Nokia xyz detected, it supports touch…). This causes many problems which can be solved, but cost time and money.

The device detection cannot know if the device is rotated, if JS is enabled etc. Responsive can work with this, adaptive cannot.

If you create multiple HTMLs for each device – you end up with a lot of „views“. This is highly ineffective and causes much redundant code, because of the many possible combinations of screen sizes, touch-capabilities, and more.

Responsive can handle each feature separately. This means, it can handle all screen sizes ideally, and then it can handle all input-capabilities (touch, keyboard, screen, mouse, disabled-reader…), and then it can be semantic, and retina-optimized and more. It’s just so much simpler.

Is Adaptive completely dead?

It’s only 99% dead. There is an approximate 1% of scenarios where it might be useful to help the responsive web. But I couldn’t name a really sensible scenario. SharePoint 2013 is still adaptive, Amazon is still adaptive, but all the examples I can think of feel more like leftovers of a previous era. I would like to note that Microsoft has also discovered this and will move on with their new strategy of „Universal Apps“. So I believe one of the last proponents of Adaptive has just given up.

What’s next?

Since we now know for sure that Responsive is the only way to go, we will continue with planning Breaking Points – a very important concept in responsive web sites.

Many people believe they can create a responsive website simply by downloading a responsive skin. This is like creating a great present simply by buying the right gift-wrapping – it barely scratches the surface.

This is part 1 of (tbd) of my special responsive/mobile series for creating professional, good looking, mobile-ready responsive web sites, which are also Retina optimized. In this series we’ll look at the process, concepts, planning, implementation, common standards, DNN tools and technologies. I always work holistically, so well look at the process from the perspective of the owner, the visual designer, the web designer, future content editors and the end user

I’m writing from personal, real-life experience. These methods and best-practices have been put to use many times in our own projects and result in extremely high customer satisfaction.

Teaser: We (2sic) will do 2 workshops around these issues at DNN-Connect in Italy May 2014 – be there!

First: Correctly Defining the Goal

So let’s do it right: Before trying to solve the problem, it’s important to define what we’re trying to achieve – and then dissect the parts. We want to…

Create a great looking website (or web solution, application, …)

…optimally presenting the content (a company, catalog, tool) in a beneficial way (usually to boost sales…)

…which optimally adapts the way it looks and behaves based on the abilities of the device and person accessing it

…and adapts in real time based on real-life changes (like device rotation)

…should look great on modern devices (like retina-displays) and function on old devices (like an ancient IE)

…content / data must be easy to update for the owner of the website (not the web designer)

Based on these goals it is clear that changing the packaging won’t work. At best, you’re just creating a responsive wrapper – but in reality you should focus on the content.

What’s the Scope of these Series?

Mobile-first and content-first (our paradigm for all professional sites nowadays)

Usability planning, mockups, best practices for responsive designs

Screen design – and planning for the 1000+ most likely variations of screens and rotations

Layout which is still ideal for the disabled (and SEO, since a spider is like a disabled person)

Layouts which still work on huge screens (nobody like rotating their head to read…)

Navigation

Navigation that works in minimal screen mode…

…and disabled mode

…and iPad / PC

…and still looks great

user orientation (where am I?) – especially difficult on tiny devices

Content Responsiveness

Re-arrange content-elements based on screen sizes and pointer-type (mouse, finger)

Show/hide content parts…

Change interactions (like introducing folding content on mobiles)

Multi-column content-layouts

Interactive Content

Change interactions from mouse to finger (galleries, …)

Change tool-dialogs to handle fat-finger handling

Completely change behavior based on device capabilities (has GPS…)

Special Image-Handling Mechanisms

Dynamic resize

Switch from large to thumbnail-with-lightbox on the fly

Uncomplicated Retina-Handling

Tables: Very difficult issue because tables don’t shrink well

Videos and highly interactive Visuals

So in general, most of these things have to do with content – not skinning. It’s cute to start with the skin, but that only works for very simple sites – like the typical WordPress-site. Everything else simply misses the point – you’re applying the paint to the house that wasn’t planned.

Google has an awesome scripts-management engine called GTM (Google Tag Manager). Though it talks about managing tags, in reality it actually manages script-integration. Particularly Google-scripts (like Adwords and tracking stuff), but also jQuery and similar.

How does it work? In general you create a „set“ of „tags“ (read: scripts w/parameters) in a web-interface provided by google. Then you integrate that set with some iFrame/Script-HTML-snippet in your layout. If one day you would like to add another tag or change the tag-integration-rules, you do this on the GTM-System, without having to modify your page. Note that the GTM-System also allows various rules, like automatically integrating different scripts depending on the page that is being viewed; adding custom parameters etc. – very powerfull.

The integration is a bit tricky with DNN, because it uses an iFrame which must be added right after the tag and before the default tag.