I’m personally looking forward to this event because I will hold two presentations and a 1-day workshop. I’m really excited about that and also a bit nervous!

Let me share with you a glimpse of my presentations.

Single-Sourcing Desktop and Mobile Websites

As the title suggests it, it is about mobile website. I will start by telling you that I don’t need to tell you that you need a mobile website, because you know already that you need a mobile website .

I will continue with a presentation of Magnolia Instant Mobile feature and to finish I will show you how to build a website for smartphone and tablet easily.

Multilingual Websites, Microsites and Landing Pages

For this presentation, I’m not alone. Will Paoli, Web Developer at Atlassian, is the other speaker.

I will start the first half with theory about how to build multilingual website and Will will show you that it’s not only theorie.

Migrating to the Latest Versions of Magnolia CMS

The last  is a workshop about Migration. I will spend a day with the bravest and will explain them all the secret of a migration to the version 4.5 of Magnolia.

I hope to see you there!

The result was already acceptable but we found a lot of drawbacks.

Now, in this second sprint I will try to solve the drawbacks with “easy” workarounds and to provide an even better solution.

But first let me summarize the problems found and explain how I will solve them.

Goal

What I want to achieve in this second sprint:
Prevent areas overriding:

• I will remove areas tag directly from the template scripts

Web pages and all the elements have to be optimized for a mobile experience:

• Review of the HTML structure
• Review of the stylesheets
• Provide properties only for the mobile website

Less loading time:

• Reduce the size of the page
• Minify the css
• Minify the javascript
• Update the images variations

Server-side mobile detection

• I will add a filter in the Magnolia filter chain managing the redirection to the mobile website

So now, you should have a better view of the different goals I want to reach.

Let’s start!

A simplified HTML structure

First, I remove directly from the main template script the includes of the promos area, extra area and other areas.

I keep only the areas I want to display on the mobile website  like branding, stage, top (horizontal) navigation, main content, down (vertical) navigation and footer.

Other scripts like branding.ftl, breadcrumb.ftl, header.ftl are also modified following the same logic.

By removing some areas from the template script I can prevent their overriding.

What I’m also doing is an update of the HTML structure, a lot of <div> tags are removed, the structure could be defined as a 1-column layout.

Here a snippet of the main.ftl

[#include def.header.branding.template]
[#if def.header.stage.enabled] [#include def.header.stage.template][/#if]
[#include def.navigation.horizontal.template]

[#if def.breadcrumb.enabled]
[#include def.breadcrumb.template]

[/#if]
[#include def.mainArea.template]
[#include def.navigation.vertical.template]
[#include def.footer.template] Go to the main site

The CSS

I create a new stylesheet for the mobile website where I define only the styles I “really” need. The stylesheet will not be overloaded with useless declarations.

For my inspiration I had a look at this CSS skeleton. It was quite  easy to start with it as I have already worked with the 960.gs  grid system.

The advantage of getSkeleton is that it comes with a bunch of media queries that provides responsive layout capabilities for different kinds of mobile devices (smartphone, tablet). Thanks to this I will manage the different mobile screen sizes (portrait vs landscape).

Once the CSS is done, I update the theme with the new minified mobile.css.

New Properties only for mobile

Configure first

Now I want to provide properties only for the mobile website like:

• A smaller logo
• And I would disable some pages from the top navigation

To achieve that I extend the page dialogs and I add two new properties.

When I open a page dialog from my main website, I can enter these two new properties.

If you know well Magnolia and the templating mechanism, you should have noticed that I was a bit to fast in my demonstration, some steps are missing…The main topic is mobile and not templating!

Anyway, I quickly show you what is missing.

First, create new templates extending the STK ones, and assign to them the dialogs “freshly” created.

And then, apply these templates to the website.

About the model

If you are familiar with Magnolia, you maybe remarked another change in the template. No, you don’t see?

There is a new model class, MobileTemplateModel extending STKModelTemplate.

This model provides the mobile logo link.

public String getMobileLogoImageLink() throws RepositoryException {
    final Content root = getSiteRoot();
    return STKUtil.getAssetLink(root, "logoMobile");
}

And contains also a new model for the mobile navigation.

public SiteNavigationModel getNavigation() {
    return new MobileSiteNavigationModel(getDefinition().getNavigation(), getSiteRoot(), content);
}

Now, I have to update the scripts of the mobile site definition in order to display the logo.

[#if model.mobileLogoImageLink?has_content]


[/#if]

And the top navigation.

[#assign navigation = model.navigation.mobileHorizontalNavigation/]

Few words about the mobile navigation

I don’t want to go too much in detail, for that you could dig into the prototype.

But at least the important points:

The mobile navigation model extends the SiteNavigationModel class.
The mobile top navigation follows the same logic than the one you can find in its parent class. It displays a page according to the property hideInMobileNav.
That’s why some pages can now be display on the main site and not on the mobile site.

For the vertical navigation, the macro in the script verticalNavigation.ftl has been changed. Only the first children of the current page are displayed.

Mobile detection

I want to improve the redirection to the mobile website.
I create a filter, its role is to detect if the request comes from a mobile browser or not, and then redirect to the corresponding website.
The analysis of the request is managed by WURFL.

The redirection is no more a redirection in the sense that we have now a single url.

According to the device requesting the content, the corresponding site definition is set.

With this solution the content is rendered differently but the URL stays the same.

public void doFilter(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        manageVisiteOfDesktopSiteFromMobile(request);
        ExtendedAggregationState aggregationState = (ExtendedAggregationState) MgnlContext.getAggregationState();
        SiteManager siteManager = SiteManager.Factory.getInstance();
        Site site = null;
        // here we could imagine to manage different families of mobile(tablet, smartphone, ...) and redirect each family to the corresponding site definition.
        if(isMobileBrowser(request))
        {
            if(isVisitingTheMainSite(request))
                site = siteManager.getSite(desktopSiteDef);
            else
                site = siteManager.getSite(mobileSiteDef);
        }
        else site = siteManager.getSite(desktopSiteDef);
        aggregationState.setSite(site);
        chain.doFilter(request, response);
    }

Maybe you has remarked that there is a link at the bottom, “Go to the main site”.

When you click on this link you are redirected to the .. well it’s obvious.
The HTML code:

Go to the main site

The filter detects if the request come from a mobile and if this parameter is set to true or false.

According to that you are redirected to the good site.

And now

After having designed some elements and doing few modifications in the imaging module, I can show you the final result.
The top navigation displays only two pages, but the others are still visible on the main site. I did also a slight redesign of all the elements.

You will recognize the home page.

For the section page I decided to hide the top navigation.

You can navigate back through the breadcrumb.

If you want to navigate down, at the bottom of the page you have the “down” navigation displaying only the first children of the current page.

An article.

And to finish, I show you the image gallery.
When you click on a image, it displays the zoom view of the image with a nice app-like effect. You can also swipe with your finger to see the next or previous image.

Conclusion

Finally the main goals are completed, the demo project min is running well on my iPhone but there is still a lot of things to do.

Anyhow you have a good overview of what you could do if you have to implement a mobile version of a website running under Magnolia 4.4.
From a project perspective the workarounds suggested are acceptable. For example it could be acceptable that you remove directly from a script an include of an area you don’t want.

If you want to continue the mobile adventure with Magnolia, I suggest few tracks on which you  could spend more times.

• Review of all the STK elements
• All the elements (templates/paragraphs) have to be redesigned
• Dialogs should provide a tab for mobile properties
• Flash vs HTML 5 video player
• Loading times (page still too big)
• Images for HD mobile
• More granularity in the mobile detection.
• Accessibility (for example iPhone VoiceOver mode)
• Integration of jQuery Mobile (or any other cool mobile framework)
• Mobile Filter improvements
• and more….

I really invite you to contribute, you could add new tasks on the mobile project space.

And if you want to run the prototype on your machine and to dig more the source, please download the demo here.

See you soon for more information about Magnolia and mobile website.

Why using the entreprise edition? I need the Extended Templating Kit module which provides multisites features (you will see later why).

This post is a bit technical, so if you don’t know well Magnolia CMS, I recommend you to have a look first  at this website.

So now, if you are ready, I will explain, steps by steps, how I create a mobile website with Magnolia.

Create the main website

First thing to do is to create the main website (or desktop website).

I start from the demo website where I remove few pages. I change the content of the main page, I keep only the teasers.

I do a lighter demo-project website because I don’t want to redesign all the pages and paragraph for this prototype…

Then I create a new site definition by copying the one from the demo project.

See in AdminCentral the main site demo-project-min.

And the site definition: demo-project-min

The configuration of the website displays on  the home page:

• a horizontal navigation
• a search box
• a stage
• a promo area
• an extra area
• a base element
• a footer
• a main area containing only internal teaser

The theme used is the pop theme.

If you know well the Magnolia world, you should be quite familiar with the setup of a website.

The main website.

First steps to the mobile site

So now, I have my main website… and it’s already great for a CMS. Let me find find a way to provide a mobile version of this site.

Magnolia EE comes with the module ETK and its powerful feature: Multisite support. It allows us to create multiple websites, each site has its own site definition, its own theme.

Let’s create new site definition and a new theme for the mobile website.

Why a new site definition?

With a site definition I’m able to hide some areas like the extra or promos areas. A  mobile website must definitively be lighter and focused on the main content.

I can also provide new template scripts in order to change the HTML structure. For example I could provide a complete different script for the main.ftl and change the whole structure of the mobile website.

Why a new theme?

A mobile theme provides stylesheets for a “mobile-ready” design. A theme is also shipped  with the images configuration. By adding new variations to this configuration we could display smaller images for the mobile website… If you want to learn more about how a same image can have different sizes on different pages or different websites, you should have a look at the imaging module.

And now?

First, I create a mobile site definition:

• extending demo-project-min site definition
• with its own domain (eg. m.localhost vs localhost)
• with its own prototype definition
• turning off some elements (promo, extra, meta are disabled)
• providing new template scripts (main.ftl, branding.ftl, ect…)
• referencing the new theme mobile-concept

And I create a new theme “mobile-concept” with:

• style.css (STK default style)
• mobile.css, this stylesheet modify the style of several elements for a better mobile experience
• new images variations in order to provide smaller versions of the images

How to detect a request from a mobile device?

I do this detection with Javascript. If you request the website from a mobile, you are redirected to the mobile website url (m.localhost), and remember that this url is mapped with the mobile site definition.

The final result

For the moment, only the home page is designed (not enough time to do the whole site).

Here you see the result on my iPhone 3GS.

You can remark that I kept the logo, the search box, the stage and the horizontal navigation is now vertical (I will name it from now top navigation… because it’s no more horizontal).

The main content contains only internal teasers… and the footer is still present but not well designed for a good mobile experience.

I modified a bit the styles in order to provide a better usability from a mobile device.

And I repeat it’s exactly the same content: same templates, same paragraphs.

It’s same same but different !!

Drawbacks

Even if it looks good, there are several drawbacks.

With the template prototype

Do you understand the following diagram?

This is what happens when a template prototype is merged with a concrete template:

• Template prototype is the basis.
• Concrete template definition adds and overrides.
• The result is exposed as the template definition (def) to the template script.

I remind you,  I have two prototype definitions (one for the main-website and one for the mobile website) and, as I share the same content, a page on the main website and a page on the mobile website return the same template definition, it’s the same page!

So what could happen if I disable an area on the mobile website (from the prototype configuration), it could be enabled by a template definition of the main website… You still follow me?

Ok, let’s take an example:

• I want to disable on every pages of my mobile website the promos areas (mobile prototype / promos = disabled)
• I want that every section pages of my main website display the promos area (stkSection / promos = enabled)

What will happen on a section page of the mobile website? Promo will be displayed! First drawback.

(It’s often the case in a project that a template definition override a property from the prototype definition.)

A solution could be to remove directly from a template script the area to hide on the mobile website.

With the paragraphs

With the paragraphs I have a similar problems, I really would like to change the script of the Internal Teaser in order to remove the abstract (and not only to hide it with CSS), but if I change the paragraph script, the abstract will be also removed from the main site.

With the HTML structure

When I did my slight redesign, I started from the HTML prototype of STK and I modified the CSS. This is the best practice when you start a new project based on STK, but this HTML prototype is not really designed for a mobile, it’s too complicated. There are too many HTML elements we dont need.
The style.css is huge and there are a lot of JS script loaded (and maybe we dont need all of them).

A solution could be to build a new HTML/CSS structure for my mobile website, more simple, based on a responsive layout.

With the switch mechanism

I really don’t like this client side solution, for any reason if the javascript is disabled on the mobile device, the user won’t be redirected to the mobile website.

I must do something on the server side, and also I have to find a way to provide the same URL for both website.

Google recommends a single URL.

What’s next

I hope that this first presentation about how to  mobilize a Magnolia website was enough clear.

It could be confusing when I speak about the main website and the mobile website, it’s two logical websites but one physical website… I’m not sure it’s more clear now!

The goal was to highlight the multisite mechanism: on the same content, according the context I can apply a different site definition, meaning a different prototypes, different areas disabled, different themes.

So finally, we could conclude that some good things were achieved in this first sprint:

• Same content displayed, no duplicated website
• Images are smaller, new variation of the imaging module

But as we saw in the drawbacks, there are still things to improve.

Give me few days for this second sprint, and I will come back with a better solution.

But before starting 2 remarks:

First, to understand the next posts, you need a strong knowledge of Magnolia and the Standart Templating Kit. You could understand that this serie of posts is more for developers.

And, if you want to achieve the same results, you need a Enterprise Edition of Magnolia (4.4.x). Why? Because I need the module Extended Templating Kit which is a EE module (you will understand later why I need this module).

What means “mobilize”?

From an existing website provide the mobile version without creating  extra content or new pages.

The same content should be available on both websites, but of course rendered differently.

Why this approach?

Usually small customers have no intention to manage a separate mobile website, they have limited resources in their IT Team, so they need a “Mobile Ready” website, the content created on the main website must be available for mobile respecting all the constraints of this new world.

Another approach (I call it Mobile Microsite) represents a specific website for the mobile world. Big customers with enough resources can manage several websites in term of infrastructure and content. The advantage of this approach is that the content could be more tailored for a mobile usage. (Maybe this approach will be part of another series of post).

One content Two websites

Before diving in the technical details, I would like to enumerate few goals to reach with this approach:

• Exactly the same content has to be used, no new page created
• Some areas have to be disabled on the mobile version like the promos area.
• The web pages and all the elements have to be optimized for a mobile experience
• Images have to be smaller
• The size of the page has to be reduced (less loading time)
• When the user access the url of the website from a mobile he has to be redirected to the mobile website, switch mechanism

So, I think it’s enough for an introduction.

If you want more details don’t hesitate to add a comment.

Why follow my blog?

After more than 5 years working in IT on many projects about web technologies, intranet, portal and content management system, I think it’s time to speak, it’s time to share. I often had ideas, sometimes stupid, but also sometime good, I think a blog could be the right place  for my thoughts. And who knows? Maybe it could help someone, one day…

Because you like developing for the web

So I will try to publish regularly posts about web development and web design.  And I will share my ideas about user interface , I started few years ago to find interest in usability and user experience, at the same time I started to learn HTML and CSS, so I would like to share some of my prototypes illustrating UX cases. The best application without a good user interface is nothing.

Because you are a Magnolia developer

If you already visited my website, you certainly remarked that I’m working for Magnolia. The idea here, it’s to feed Magnolia developers with hints, tutorials, ideas, piece of code and… Hey wait! Follow my blog if you want to know what is comming.

I will also publish articles about Magnolia in my mother tongue, French (I guess you realized that I’m not a native english, but another french guy trying to speak englisheu). There is a lack of documentations / articles in French, and the french community of Magnolia developers deserve also to know how being succesful with Magnolia!

Nota bene

As I said before, my website is done with WordPress (I hope my bosses are not reading this post). When I created this website one year ago, I said: “Whoua, it’s so easy to develop with WordPress”. Now, after 9 months working with Magnolia, for the update of my website, I said: “P*****, It’s a pain to work with WordPress”.  I don’t say that because now I’m working for Magnolia, but it’s really more easy to deliver a website with Magnolia than with WordPress, especially if you are a Java developer like me. Sorry PHP, I’m not from your world! My argument will be based on an upcoming post about “How to release a website with  Magnolia in less than 40 hours”.

What else? Yes, if you try to click on the links in the top, some of them are not working (but soon). Also I tested my website with Firefox 3.6 and Chrome. Sorry if you try to read this page with IE, you will encounter some troubles… but I assume that if you really like web development, you  hate IE.

And to finish, all comments are welcome.

See you soon for a new post!

]]> http://www.samuelschmitt.net/2011/01/senior-it-consultant/feed/ 0 http://www.samuelschmitt.net/2010/09/software-engineer/ http://www.samuelschmitt.net/2010/09/software-engineer/#comments Mon, 13 Sep 2010 13:37:22 +0000 Samuel Schmitt http://127.0.0.1/wordpress/?p=108 The goal of this web application is to provide a tool allowing an IT Asset Inventory.

• Management of the assets
• Management of the maintenance contracts

Java J2EE, Spring 2.5, Hibernate 3, Spring security 2.0, Jquery, HTML, CSS

My main task was to suggest a technical recommandations to the customer, and to re-develop this application according to these recommandations.

• Web architecture
• Code refactoring

J2EE, Struts 1.1, Hibernate 3.0, jQuery, Oracle 10, Oracle Weblogic Workshop 10.3, Oracle Weblogic Server 10.3

• Objectives definition
• Social network strategy
• Offshore services management
• Project Management

IBM Lotus Connections 2.5

• Definition of the requirements for the new version of the intranet
• Design and development of new functionalities
• Test and validation
• Data migration from WP 5 to WP 6
• Portal layout design, portal theme customization
• WCM design and customization
• IBM Websphere portal 6 administration

Integration of a collaboration platform – IBM Lotus Quickr

• Quickr 8.0 Theme
• Quickr 8.0 integration
• Quickr administration

J2EE, JSP/Porlet, JSF, IBM Websphere Portal 6, WCM, IBM WAS, Quickr