Posts in Category: Site Design

Some Cool New mojoPortal Sites

Just a quick post to highlight a few cool mojPortal sites that have com to my attention recently.

12th Street Sports Bar - Tim Cartwright of US Interactive did a great job with this site for the show on Fox College Sports TV Channel.

12th Street Sports Bar

b square, a site designed by TEAK. Notice that they implemented multiple languages and a cool language switcher and this was done with no changes to the core of mojoPortal.

Bsquare designed by David Dean, as David describes the site, " is a new concept that allows anyone who is an expert in a field to easily post course descriptions, and deliver live content in unique virtual rooms. The site is not even at an alpha stage, but early adopters can register and launch instant meetings or schedule online meetings for free. It's a webex like experience (that part is not mojo), with enhanced meeting rooms that allow for visual, non-verbal feedback coming soon."

Antioch Community Church designed by Joe Davis of i7 Media. I really like the menu design with 2 levels of horizontal menus. Joe has even made a free skin available to the community with a menu design like this.

Antioch Community Church

Adamson UAE, submitted to our Success Stories Forum just this morning has a very nice design.

Adamson UAE is a site brought to my attention recently. The most interesting thing is that the site is running on Linux using Mono.

If you're doing cool things with mojoPortal let us know, we'd love to hear from you.

On a side note, this site is running the latest code testing new features for the coming release. As you'll notice for this blog post I'm now using IntenseDebate for the comments. I've also implemented support for Disqus so you will have a choice to use that as well though I'm currently finding some issues with Disqus that I'm hoping they can fix on their end or advise me on what I can do. I've added a new setting in the blog where you can choose the comment system with options Internal, IntenseDebate, and Disqus. I also implemented it such that if you have existing posts with comments already made using the internal comment system, those posts will continue to use the internal comment system but new posts will use the currently selected comment system. So this is my first post using IntenseDebate. I look forward to seeing if this increases the amount of comments or not. 

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

Issues and Strategies for Moving to Html 5

Primer on Html 5

There has been a lot of buzz in the blogosphere about HTML 5 lately, from google endorsing it as the future to the W3c dropping efforts on XHTML 2 to focus on HTML 5. The consensus seems to be that HTML 5 is the future and we should start planning on using it in the future and can even use it now. It should be noted however that HTML 5 is not a standard yet, but only a draft and is subject to change before it becomes a standard and current browser support is a mixed bag.

Some useful links:

23 Essential Resources for Html 5

Misunderstanding Markup - comic that explains HTML 5 vs XHTML.

Real World Issues for a Content Management Systems To Switch to Html 5

So from reading the above linked articles and others it seems like we can easily change to the HTML 5 DocType and things will be pretty much compatible at least as long as we don't use any of the new HTML 5 elements that might not be supported in all browsers yet. In mojoPortal the doctype is declared in the layout.master file of a skin so it can be a personal choice wheether to change to the Html 5 doctype now or not. Currently the doctype in our skins is XHTML 1.0 Transitional, so to switch to HTML 5 we would just change this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="" >

to this:

<!DOCTYPE html>

In fact I've done that here on, though I'm running a newer build than the current release (dogfooding for the coming release), so you should probably wait for the next release to do this if you want to. One of the things I've added is an option on our validator link to configure it for HTML 5 instead of XHTML like this in layout.master:

<portal:XhtmlValidatorLink id="lnkw3cValidator" runat="server" UseImage="false" Html5="true" />

This Html5=true merely changes the label and/or image on the validator link to HTML 5. I've also added a property IncludeHtml5Script to our IEStyleIncludes control

<portal:IEStyleIncludes id="IEStyleIncludes1" runat="server" IncludeHtml5Script="true" />

if set to true we inject the javscript as mentioned in this article inside IE browser comments to make it possible to use some of the new HTML 5 elements in IE 8 (though I'm not actually using them yet to avoid compatibility issues you could use them in custom features). So it renders in the page like this:

<!--[if IE]>
<script type="text/javascript">


Ok But Aren't There Any Gotchas?

I got kind of excited about changing the doctype to Html 5 just in preparation for the future even though we can't use the new Html 5 elements yet without breaking some browser compatibility, especially for IE 6. I'm sick of caring about IE 6 myself and admittedly some of our skins are a little funky in IE 6 today and I don't care enough to fix them though some of them work pretty well too. Its long overdue for users of IE 6 to upgrade. But its still in wide enough use that many web site owners do care and you can make skins that work well in IE 6 using mojoPortal its just more work tweaking the IESpecific.css file and testing in IE 6. Anyway after changing to HTML 5 doctype on and testing in IE 6 and not seeing any major problems I thought I would change the included skins to HTML 5 for the next release. I did this yesterday but reverted it today. I had been testing using the wc3 validator using the direct input method, viewing the source of the page and pasting it into the validator and was happy because it was reporting it as valid HTML 5. However after testing some pages on using the validator link or using the url input method I got different results. It seems there is a bug in the w3c validator where if you use direct input it passes things that should not pass but when you use the url it finds problems on the same page it validated as direct input.

Specifically what I ran into was border is not a valid attribute on img and frameborder and scrolling are not valid attributes on iframe, however the presence of these attributes does not seem to be detected correctly with the direct input validation but it is detected using url validation. I reported this bug to the w3c public mailing list tis morning. Fixing the border on img was fairly easy so I did that, you can easily set the border on img using css so its really not needed to use border="0" to remove a border for example. However the iframe issue is a lot more of a problem. If you remove frameborder="0" from an iframe there is no way to remove the 3d border that is rendered in current browsers using CSS. I don't think there is a working CSS alternative to scrolling="no" either. So for the moment I choose to just live with it that a few pages on won't validate but for the skins included in mojoPortal I decided it was pre-mature for me to change the doctype to HTML 5 and changed it back and leave it up to users if they want to do that. 

As previously mentioned, HTML 5 is currently just a draft so I don't want to get too concerned with validation against it while its still draft. Who knows since current browsers don't work well look right with iframes that don't use frameborder=0 and scrolling=no, maybe they will change their minds about dropping these attributes or give us an HTML 5 Transitional to validate against that will allow these for backward compatibility.

So where does that leave us?

Well I think we have to proceed cautiously and very slowly toward HTML 5 but we are very limited in what we can do in mojoPortal without breaking compatibility especially for public facing features. If I were to start using new elements and attributes of HTML 5 it will break validation for those who choose to continue using the XHTML 1.0 Transitional doctype in their skins and it would probably break functionaility and visual layout in some browsers. Potentially we could move forward in the admin pages and other non public facing pages but the benefits would be minimal. The real value of HTML 5 will be when we can use it for public facing pages, the improved semantics available using the new elements like header, footer, section, nav, article, aside etc will be of most value in public facing pages, but we really can't move there yet because of the mixed browser support. Once HTML 5 graduates to a Standard instead of a draft and browser support for the new elements is more widespread it will be tempting but we will still be faced with that fact that many people use old browsers, perhaps even we will be waiting for the end of life of the current crop of browsers anxiously like we are waiting for IE 6 to go away today. The benefits of changing to HTML 5 doctype today are minimal and there is the minor downside of losing validation on some pages where we are using iframes and maybe other issues that I have not bumped into yet. HTML 5 does indeed look like the future but the future is not here yet unless you are willing to give up support for IE 6 and possibly even IE 7 as I'm not sure if the javascript trick for lighting up the new elements in IE works in IE 7 as it does in IE 8. (update it does work) I for one don't see the merit in building browser specific applications, the huge benefit of the web has been the ability to write apps that work in all browsers though of course there have been bumps along the way like supporting Netscape 4 was back in the day and like supporting IE 6 is today, it takes some extra work. I don't want to try and move forward too fast and find myself battling to get things working in all browsers. I'm tempted to change my doctype on this site back to Xhtml 1.0 Transitional since I'm not really getting any benefit from changing to HTML 5 doctype though I have not had any major problems other than some validation issues everything seems to work the same and nothing is visually different in any of the browsers I tested.

UPDATE 2009-08-03

I actually tried this javascript create element technique with IE 6 and it seems to work! So even though the article says IE 8, it seems it should also work for IE 6 and 7. So maybe it is possible to switch to Html 5 and use the new elements. So the remaining issues would be that there will be some things that don't validate like framborder=0 and scrolling=no that we would still need to use. And the problem still remains that if I were to start using the new html5 elements that would mean that all users of mojoPortal would need to change to the Html 5 doctype because the new html 5 elements are not valid for Xhtml.


Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

mojoPortal used in the We Are Microsoft Charities Challenge Weekend

Over the weekend, Jan 16-18 2009, Microsoft held a great event, "We are Microsoft Charity Chellenge Weekend" to help charities. The event paired teams of developers with charity organizations to produce web solutions to better meet the needs of the charity organizations. The challenge was that the time available to produce the solution was limited to the weekend, everything from gathering requirements to final delivery had to be completed in that time frame.

I was very honored when one of the teams chose to use mojoPortal.

paxUnited Team - Microsoft Charity Challenge Weekend

Todd Stone, Tim Mitchell, Nathan Woodward, Jay Smith, Andrew Dalgleish

You can read the full details and see before an after screenshots in this blog post by Microsoft MVP Jay Smith "We Are Microsoft: Developers Rally Around Charities"

"After checking out Telerick’s SiteFinity and Telligent’s Graffiti CMS, both very powerful and capable Content Management Systems, we elected to go with mojoPortal."

These guys really did an impressive job accomplishing so much in a very limited time frame. I congratulate them and thank them for their good work for a good cause and for giving mojoPortal the oportunity to participate in this exciting event.

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

A Few New Tutorials

Just a quick post to mention a few new tutorials for mojoPortal.

How To Filter Out Un-Wanted Content From Feed Manager

by Walter Ferrari of Abertech. Big thanks to Walter! He not only helped with major improvements to the Feed Manager recently but also is willing to help with documentation which is much appreciated.

CSS - Its All About Understanding Selectors

an article I wrote today to demystify CSS a little for those trying to learn how to skin mojoPortal. Once you master CSS Selectors it becomes much easier.


Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

Tip/Trick Creating tabs in the mojoPortal Html Content Module

In the mojoPortal release announcement, I mentioned that we changed from ExtJs tabs to YUI tabs in mojoPortal. One side benefit of this is that its now possible to create tabs in your content using the editor.

In the past this wasn't possible. I had written a .NET wrapper control around the ExtJs tabs, but only developers could use that, there was no simple way to create tabs right in your content. The integration with YUI tabs is a little looser, I have not implemented a .NET control for it yet though I may do so in the future. But the main scripts for YUI tabs are included by default, so you can paste a simple chunk of markup into the source view of the editor to get the start of your tabs, and then you can edit it from there to add more tabs or change the labels and contents of the tab.

Now you won't see the tabs in the editor, but when you save it you will see the tabs.

To try it out, add an Html Content instance to a page in your mojoPortal site or on our demo site. Click the edit link to edit the content, then click the source button to see the raw markup view. Now paste in this:

<script type="text/javascript">
var myTabs = new YAHOO.widget.TabView("demo");
<div class="yui-skin-sam">
<div id="demo" class="yui-navset">
<ul class="yui-nav">
<li class="selected"><a href="#tab1"><em>Tab One Label</em></a></li>
<li><a href="#tab2"><em>Tab Two Label</em></a></li>
<li><a href="#tab3"><em>Tab Three Label</em></a></li>
<div class="yui-content">
<div><p>Tab One Content</p></div>
<div><p>Tab Two Content</p></div>
<div><p>Tab Three Content</p></div>

Save, and you will see something like this:

screen shot of YUI tabs

At some point when I implement content templates I will make it easy to do this by selecting a content template, but thought I would mention it for the more html savvy users.

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.