Fork me on GitHub
2sxc 8.11 for DNN 7 to 9
Website Builder, Content Manager, App-System: free and amazing - done your way
You are here: Home  >  Learn  >  Blog English
von iJungleBoy am 10.7.2014

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 :(.

So I created a App for that. You can find it here SyntaxHighligter App and a quick demo here. Enjoy!

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…

  1. …an installed Apps (modules) couldn’t contain server-code like C#
  2. …and thereby could not crash the server, no matter what
  3. …and could not contain DB-access code to „private“ information?
  4. …and the Apps would not be centralized, but an own install per portal

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

  1. …give admins / web-designers the right to install Apps (not possible right now, too much risk)
  2. …give admins / web-designers the right to modify Apps as they need to (without host-permissions)
  3. …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:

  1. Modification of strings (done in JS)
  2. Selectable Color-Schemes (done with well-selected value-names in the dropdown so you don’t need code)
  3. Selectable programming language causing different systems to run (done with good dropdowns & logic in JS)
  4. Prevent multiple copies of CSS & JS (done using DNN-Resources-Bundling and some JS)
  5. SEO enabled (done using standard HTML)
  6. Editing data-UIs with Multi-Language UIs (done with 2sxc)
  7. Multi-Language output (done with 2sxc)
  8. 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 🙂

Yours from Switzerland
Daniel


von iJungleBoy am 15.5.2014

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:

  1. Fastest code: using a simple SQL-Reader
  2. A bit more comfy: using a DataTable
  3. With typed POCOs: using PetaPoco
  4. Nicest: using 2SexyContent DataPipelines (SqlDataSource)
  5. Nicest but with more complexity if needed: using 2SexyContent DataPipelines with manual data (DataTableDataSource)

BTW: the easiest way to try this out and to play with the code is to

  1. Install a new DNN (7.2+)
  2. Install 2SexyContent 6.0.6+ in the DNN
  3. Install this SQL with Razor Data-Demo-App with all the samples here included

The SQL samples are described and documented here.

For just quickly looking at the results, you can find it all here on the page with the app-demo.

#1 Fastest code: using SQL Reader

@using System.Configuration

@using System.Data.SqlClient

@{

       var conString = ConfigurationManager.ConnectionStrings[Content.ConnectionName].ToString();

       var con = newSqlConnection(conString);

       con.Open();

       var command = newSqlCommand(„Select Top 10 * from Files Where PortalId = @PortalId“, con);

       command.Parameters.Add(„@PortalId“, Dnn.Portal.PortalId);

       SqlDataReader myReader = command.ExecuteReader();

}

<divclass=“sc-element“>

       @Content.Toolbar

       <h1>Simple Demo using DataReader access</h1>

       <ol>

             @while (myReader.Read())

             {

                    <li>@myReader[„FileName“]</li>

             }

       </ol>

       @{

             con.Close();

       }

</div>

Pros

  1. Easy – copy paste etc.
  2. Standard .net, no learning curve
  3. Probably best performance of all shown samples because almost no abstractions

Cons

  1. Only forward looping through the reader
  2. Code feels technical and maybe difficult
  3. Can’t use 2sxc pipelines
  4. Can’t use 2sxc-built-in serializers and other features

#2 More Comfy: using DataTable

@using System.Configuration

@using System.Data

@using System.Data.SqlClient

@{

       var conString = ConfigurationManager.ConnectionStrings[Content.ConnectionName].ToString();

       var sqlCommand = „Select Top 10 * from Files Where PortalId = @PortalId“;

       var adapter = newSqlDataAdapter(sqlCommand, conString);

       adapter.SelectCommand.Parameters.Add(„@PortalId“, Dnn.Portal.PortalId);

       var fileTable = newDataTable();

       adapter.Fill(fileTable);

      

       // for the demo, apply some operation to the data

       fileTable.DefaultView.Sort = „FileName DESC“;

}

<divclass=“sc-element“>

       @Content.Toolbar

       <h1>Simple Demo with DataTable access</h1>

       <h2>The top 10 files found in this portal as returned from DB</h2>

       <ol>

             @foreach (DataRow row in fileTable.Rows)

             {

                    <li>@row[„FileName“]</li>

             }

       </ol>

 

       <h2>The top 10 files found in this portal with reverse sorting</h2>

       <ol>

             @foreach (DataRow row in fileTable.DefaultView.ToTable().Rows)

             {

                    <li>@row[„FileName“]</li>

             }

       </ol>

</div>

Pros

  1. Standard .net, no learning curve
  2. Allows further data manipulation in memory
  3. You can use the data a few times (reader is forward-only)
  4. Connection handling open/close is done automatically by the Adapter

Cons

  1. Code feels technical and maybe difficult
  2. no nice Object.Property-syntax
  3. Can’t use 2sxc pipelines
  4. Can’t use 2sxc-built-in serializers and other features

#3 With typed POCOs: using PetaPoco

@functions

{

       // for PetaPoco you must first create a class containing the fields you want

       privateclassfileRecord

       {

             public int FileId {get;set;}

             public string FileName { get; set; }

             public int Size { get; set; }

             public int FolderId { get; set; }

       }

}

@{

       var sqlCommand = „Select Top 10 * from Files Where PortalId = @0“; // PetaPoco requires numbered parameters like @0 instead of @PortalId

 

       var db = new PetaPoco.Database(Content.ConnectionName);

       var files = db.Query<fileRecord>(sqlCommand, Dnn.Portal.PortalId);

            

}

<divclass=“sc-element“>

       @Content.Toolbar

       <h2>The top 10 files found in this portal as returned by PetaPoco</h2>

       <ol>

             @foreach (var file in files)

             {

                    <li>@file.FileName</li>

             }

       </ol>

 

</div>

Pros

  1. Typed data
  2. Entity-Framework-like feeling without needing pre-compile
  3. Less code than the other direct data methods (SQL & DataTable)
  4. Short, brief syntax
  5. Would already support paging and other features (read the PetaPoco docs)

Cons

  1. Requires you to write classes for each type you need
  2. Lots of boilerplate / plumbing code for typed classes
  3. Numbered Parameters @0 instead of @PortalId
  4. Default mode with Query is forward-only like using a SQLReader
  5. Can’t use 2sxc pipelines
  6. Can’t use 2sxc-built-in serializers and other features

#4 Nicest: using 2SexyContent DataPipelines (SqlDataSource)

@using ToSic.Eav.DataSources

@functions

{

       public override void CustomizeData()

       {

             var source = CreateSource<SqlDataSource>();

             source.ConnectionStringName = Content.ConnectionName;

            

             // Special note: I’m not selecting * from the DB, because I’m activating JSON and want to be sure that no secret data goes out

             source.SelectCommand = „Select Top 10 FileId as EntityId, FileName as EntityTitle, Extension, PublishedVersion, Size, UniqueId, FileName FROM Files WHERE PortalId = @PortalId“;

             source.Configuration.Add(„@PortalId“, Dnn.Portal.PortalId.ToString());

             Data.In.Add(„FileList“, source.Out[„Default“]);

       }

}

<br/>

<divclass=“sc-element“>

       @Content.Toolbar

       <h1>Automatic 2sxc Pipeline SqlDataSource</h1>

       <p>This demo uses the 2sxc Pipeline (req. 2sxc 6.0.6+). More info <ahref=“http://2sexycontent.org/en-us/docsmanuals/feature.aspx?feature=2579&#8243;target=“_blank“>here</a>.</p>

       <h2>The top 10 files in this portal as returned by the Pipeline</h2>

       <ol>

             @foreach (var file in AsDynamic(Data.In[„FileList“]))

             {

                    <li>@file.FileName</li>

             }

       </ol>

</div>

Pros

  1. Typed / dynamic entities
  2. nice syntax, same as any other 2sxc data
  3. Easy to configure
  4. Configuration instead of programming (less error-prone and less security risks)
  5. Benefits from automatic Configuration-Injection (like when @IdFilter can be [QueryString:ProductId|0] )
  6. Entity-Framework-like feeling without needing pre-compile
  7. Less code than all other methods (SQL Reader, DataTable, PetaPoco)
  8. No boilerplate / plumbing code (like PetaPoco)
  9. Can benefit from other pipeline-features like additional filtering, paging, attribute-stripping
  10. Can be auto-serialized using 2sxc and is then in the default format for JavaScript use – try here

Cons

  1. Probably a bit more performance overhead
  2. Might not fit all complex scenarios
  3. No built-in paging like with PetaPoco, probably in the near future

#5 Nicest with control: 2SexyContent Table-DataPipelines (DataTableDataSource)

@using System.Data

@using ToSic.Eav.DataSources

@functions

{

       // Official place to provide data preparation. Is automatically called by 2SexyContent

       public override void CustomizeData()

       {

             var res = CreateResourcesSource();

             res.Source.Rows.Add(1031, „de-de“, „Deutsch“, „Herzlich Willkommen“, „Schön, dass Sie dies lesen, bitte haben Sie Spass!“, „Vorname“, „Nachname“);

             res.Source.Rows.Add(1033, „en-us“, „English“, „Welcome“, „Thanks for looking at this!“, „First name“, „Last name“);

             Data.In.Add(res.ContentType, res.Out[„Default“]);

 

             // enable publishing

             Data.Publish.Enabled = true;

             Data.Publish.Streams = „Default,UIResources“;

       }

 

       private DataTableDataSource CreateResourcesSource()

       {

             var dataTable = newDataTable();

             dataTable.Columns.AddRange(new[]

             {

                    new DataColumn(„EntityId“, typeof(int)),

                    new DataColumn(„EntityTitle“),

                    new DataColumn(„Language“),

                    new DataColumn(„Title“),

                    new DataColumn(„Introduction“),

                    new DataColumn(„FirstNameLabel“),

                    new DataColumn(„LastNameLabel“)

             });

             var source = CreateSource<DataTableDataSource>();

             source.Source = dataTable;

             source.ContentType = „UIResources“;

             //source.TitleField = „FullName“; // not necessary because we’re already using the default

             //source.EntityIdField = „EntityId“;// not necessary because we’re already using the default

             return source;

       }

}

 

<divclass=“sc-element“>

       @Content.Toolbar

       <h1>Simple Demo with custom data (for example to use non-SQL data)</h1>

       <p>This demo uses the 2sxc Pipeline (req. 2sxc 6.0.6+). More info <ahref=“http://2sexycontent.org/en-us/docsmanuals/feature.aspx?feature=2580&#8243;target=“_blank“>here</a>.</p>

       <h2>These entities resources are constructed by code</h2>

       <ol>

             @foreach (var resource in AsDynamic(Data.In[„UIResources“]))

             {

                    //var resource = AsDynamic(eRes);

                    <li>@resource.EntityTitle – @resource.Title</li>

             }

       </ol>

</div>

 

Pros

  1. Typed / dynamic entities
  2. lots of control over object structure
  3. nice syntax, same as any other 2sxc data
  4. any kind of source could be used – XML, file-lists, etc.
  5. Entity-Framework-like feeling without needing pre-compile
  6. Can benefit from other pipeline-features like additional filtering, paging, attribute-stripping
  7. Can be auto-serialized using 2sxc and is then in the default format for JavaScript use
  8. to see the automatic RSS-feed try here

Cons

  1. Probably a bit more performance overhead
  2. more boilerplate / plumbing code (like PetaPoco)

Hope you liked it…

give me feedback, yours truly, iJungleboy


von iJungleBoy am 5.5.2014

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:

WYSIWYG - Options

  1. The image could go above the title (which it actually does after a while)
  2. The image could go between title & text (which it also does for a while)
  3. It could go under the text
  4. We could remove it
  5. The size could change
  6. It could become super-tiny with a click to view (not shown)
  7. It could be replaced with an icon with a click to view (not shown)
  8. …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:

WYSIWYG Code Snippet Basic

And here the annotated version

WYSIWYG Code Snippet Annotated

  1. special classes to ensure correct display-behavior based on various rules/screens
  2. some content inserted more than once
  3. 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).

  1. a classic list with images which looks different on every screen size
  2. an overview page with content that can be 2-column or 1-column
  3. here is a before-after widget that must change behavior based on the situation
  4. this content-rotator hides some information if the screen gets too small

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:

  1. UI for the editor to add content…
  2. …to a Content-Management-System
  3. …so that the Content-Management-System can show the content to a user…
  4. …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?

  1. 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.
  2. 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.
  3. 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

  1. Inline images and all the necessary features for alignment and such
  2. Font-definitions – this always was bad practice, and now it’s really time to go
  3. 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
  4. Inline videos
  5. 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.

…to be continued…

With Love from Switzerland

Daniel


von iJungleBoy am 3.5.2014

This is a follow up to my previous blog post how to integrate Google Tag Manager (GTM) into DNN. The post had about 150 reads so I believe there’s a need for a packaged App.

Now that we can create simple Apps within minutes, it’s much easier to distribute such simple functionality.

So I created a Google Tag Manager App, just for you 🙂
– Enjoy, and give me feedback.

Stay sexy!

Daniel


von iJungleBoy am 30.4.2014

The concept of DNN Modules has many weaknesses. What we dislike most (and just fixed) are things like…

  1. If you install them, DNN might stop working
  2. If you remove them, DNN might stop working
  3. The module can only be installed once – which causes problems with upgrades and if you want to customize it…
    1. …assuming you can actually customize them – which is usually very hard…
    2. …because most module developers just develop what they think is important, and customizing is usually very late in the process
    3. though most modules may be open source, they use odd technologies and architectures making it inefficient to customize – it’s often cheaper to just develop the thing again
  4. Most Modules are not multilingual, or not the way we need it
  5. Developing modules needs visual studio to develop, compile, test, etc.
    1. Adapting them – if the code is available – needs visual studio to develop, compile, test, etc.
    2. 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

  1. Parent-Child (or List/Details) data and views
  2. Content is multi-lingual
  3. Templates are multi-lingual (using central resources)
  4. App has central settings that apply to all uses
  5. AJAX-Lightboxes for users, „normal“ pages for Google
  6. Versioned data (yes, you can get back the data as it was before)
  7. 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…)

Try it out for yourself

  1. Download 2SexyContent 6.0 from GitHub (it’s stable, but not on codeplex yet, because we need a few more instructions before showing it to the masses)
  2. Play with the App I created in 10 minutes
  3. Discover other Apps from the catalog
  4. …or contribute your own Apps – we would really love that!

With love from Switzerland – stay sexy 🙂

Daniel


von iJungleBoy am 29.4.2014

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.

What is an Adaptive Strategy?

Adaptive Strategy: Sending each device the correct HTML, CSS, etc. Basically it’s when you’re doing server-side adjustment to the viewing device. Some examples:

  • Amazon.com sends PCs a huge, cluttered, messy web page, while mobile devices receive a very simple, reduced web page
  • One of the core „features“ of ASP.net MVC is that you can „give each device a different view“ – there are special mechanisms built in to group devices, detect them and give each group another view

What is a Responsive Strategy?

Responsive Strategy: When the HTML, CSS etc. responds to the environment it’s in (the browser, window-size etc.) and modifies it’s behavior. Basically it’s doing client-side adjustments. Some examples:

  • Most wordpress blogs
  • The sales-training portal of Ricardo (something like ebay)
  • The website of the IOR (AKA Vatican Bank)
  • …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:

  1. 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.
  2. 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 todayBlog-2014-04-29 Google Trends Responsive Adaptive 2014-04-29

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

  1. 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.
  2. The device detection cannot know if the device is rotated, if JS is enabled etc. Responsive can work with this, adaptive cannot.
  3. 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.
  4. 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.


von iJungleBoy am 28.4.2014

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…

  1. Create a great looking website (or web solution, application, …)
  2. optimally presenting the content (a company, catalog, tool) in a beneficial way (usually to boost sales…)
  3. …which optimally adapts the way it looks and behaves based on the abilities of the device and person accessing it
  4. …and adapts in real time based on real-life changes (like device rotation)
  5. …should look great on modern devices (like retina-displays) and function on old devices (like an ancient IE)
  6. …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?

  1. Mobile-first and content-first (our paradigm for all professional sites nowadays)
  2. Usability planning, mockups, best practices for responsive designs
  3. Screen design – and planning for the 1000+ most likely variations of screens and rotations
  4. The perfect solution for Retina-Displays (very easy = cheap)
  5. Content resizing and wrapping strategies (requires very special HTML inside content)
  6. Extreme focus on content-design: our contributors can’t write HTML
  7. Galleries, information lists and touch-interactions
  8. Responsive tables and don’t fit a micro-screen
  9. Site navigation strategies in the Micro-UI

The Real Issues

For the initial overview – these are most core issues in a responsive design

  1. General Visuals & device sizes (that change on-the fly because the device rotates)
  2. Resolutions (like Retina-displays)
  3. Layout
    1. Arrangements based on different devices
    2. Which sizes should show/hide what elements
    3. Layout which is still ideal for the disabled (and SEO, since a spider is like a disabled person)
    4. Layouts which still work on huge screens (nobody like rotating their head to read…)
  4. Navigation
    1. Navigation that works in minimal screen mode…
    2. …and disabled mode
    3. …and iPad / PC
    4. …and still looks great
    5. user orientation (where am I?) – especially difficult on tiny devices
  5. Content Responsiveness
    1. Re-arrange content-elements based on screen sizes and pointer-type (mouse, finger)
    2. Show/hide content parts…
    3. Change interactions (like introducing folding content on mobiles)
  6. Multi-column content-layouts
  7. Interactive Content
    1. Change interactions from mouse to finger (galleries, …)
    2. Change tool-dialogs to handle fat-finger handling
    3. Completely change behavior based on device capabilities (has GPS…)
  8. Special Image-Handling Mechanisms
    1. Dynamic resize
    2. Switch from large to thumbnail-with-lightbox on the fly
    3. Uncomplicated Retina-Handling
  9. Tables: Very difficult issue because tables don’t shrink well
  10. 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.

With Love from Switzerland,

Daniel


von iJungleBoy am 11.3.2014

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.

To learn more about GTM, visit the Google Tag Manager website.

To integrate your tag, use this snippet in your default.ascx (remember to replace the xxxx with your code). Note: this works with DNN 6+ and 7+.

 

<script runat="server">
     protected override void OnInit(EventArgs e)
     {
         base.OnInit(e);
         var tp = (CDefault)Page;
         tp.FindControl("Body").Controls.AddAt(0, new Literal() { Text = "<!-- Google Tag Manager --><noscript><iframe src='//www.googletagmanager.com/ns.html?id=GTM-XXXX'height='0' width='0'style='display:none;visibility:hidden'></iframe></noscript><script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='//www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'scr" + "ipt','dataLayer','GTM-XXXX');</scr" + "ipt><!-- End Google Tag Manager -->" });
           
     }
 </script>

By the way – the easiest way to test and use this is by trying the DNN App for GTM I created.


von Raphael Müller am 18.9.2013

With 2SexyContent 5.3, we introduced the relationship feature. This means that some sets of information can be related to each other. For example, a blog entry that has a specific author or multiple categories.

We’ve also created a video about relationship management, watch it here.

Preparing the Content Types

First, create the Content Types you want to connect. These types could look like this, if you have a blog entry and author:

Blog Entry

  • Title (String)
  • Description (String with WYSIWYG option)

Author

  • Name (String)
  • Description (String with multiline-option)
  • Image (File)

To enable users to choose an author for each blog entry, create a field named Author with the new field-type Entity.

EAVManagement-Author1

Then configure the EntityType field for the author, set it to Author (the name of the Content Type for authors).

EAVManagement-Author2

After that, you should be able to choose an author for every entry you edit:

EAVManagement-Author3

It’s also possible to enable the selection of multiple entities. Check the AllowMultiValue (configuration of the entity field).

Using in a template

Now that you can enter the data with relationships, you might want to output this in a Razor templates (Token templates do currently not support relationships).

If you have the same content type structure as in the example above, you can paste this into your template:

<br /><br />&lt;h1&gt;@Content.Title&lt;/h1&gt;<br />&lt;p&gt;@Html.Raw(Content.Description)&lt;/p&gt;<br /><br />@* If an author is selected, show it *@<br />@if(Content.Author.GetType() != typeof(String) &amp;&amp; Content.Author.Count &gt; 0) {<br />    var Author = Content.Author[0];<br />    &lt;h2&gt;About the author @Author.Name&lt;/h2&gt;<br />    &lt;img src="@Author.Image?h=100&amp;w=100" alt="@Author.Name" /&gt;<br />    &lt;br /&gt; <br />    @Author.Description<br />}<br /><br />

This will show the author, if it has been selected. Line 5 makes sure the template still works if no author has been selected. Line 6 defines the variable Author as the first Author in Content (note: The field Author could also contain multiple authors).

To list all assigned authors (or any other list of assigned entities), wrap the author HTML into a foreach loop:

<br /><br />@* Show all authors *@<br />@if(Content.Author.GetType() != typeof(String) &amp;&amp; Content.Author.Count &gt; 0) {<br />    foreach(var Author in Content.Author)<br />    {<br />        &lt;div&gt;<br />            &lt;h2&gt;About the author @Author.Name&lt;/h2&gt;<br />            &lt;img src="@Author.Image?h=100&amp;w=100" alt="@Author.Name" /&gt;<br />            &lt;br /&gt; <br />            @Author.Description<br />        &lt;/div&gt;<br />    }<br />}<br /><br />

Have fun trying out the new relationship features, we hope you like it! If you have any questions, feel free to contact us at info@2sexycontent.org or visit 2sexycontent.org

Raphael


von iJungleBoy am 10.9.2013

I just finished my video and code-samples for the JS-API. I believe it will really help you get started, so dig in! http://2sexycontent.org/en-us/learn.aspx#FancyDetail-1705

Hope you love it!
Daniel / iJungleboy


2serve . 2invent . 2create is 2be.