We have been busy working on new features since we released GateIn 3.6. Today, I would like to announce two new versions of the Portal: 3.7.0.Final and 3.8.0.Beta01. Both of them are available for download already. They will be followed by the version 3.8.0.Final within a couple of weeks.

New and noteworthy in GateIn 3.7.0.Final

• Disabled Users - Administrator can now disable users thus preventing them from accessing the portal. See GTNPORTAL-3227 and Disabled User and Manage Users and Groups chapters of GateIn Documentation. Please note that when reusing a database from a previous Portal version, this feature requires migration step as described in Disabled User chapter of the documentation.
• Restricted Page Editor - An enhancement in Page Editor and Site Layout editor. It introduces a fine-grained control over who can use and change which parts of a portal page or site. Additionally, it is possible to show site header/footer preview when editing a page, and use the preview mode by default. See GTNPORTAL-3263, GTNPORTAL-3272 and GTNPORTAL-3259 as well as the documentation in Restricted Page Editor wiki page and Manage Permissions chapter of GateIn Documentation.
• Wildcard (*) Membership Type - see GTNPORTAL-3349 and Wildcard (*) Membership Type chapter of GateIn documentation.
• Profile for packaging with EAP 6.2.0.Beta - see GTNPORTAL-3318
• All features, bug fixes and minor enhancements are covered in GateIn 3.7.0.Final Release Notes.

New and noteworthy in GateIn 3.8.0.Beta01

• There is no JBoss AS 7 distribution any more. JBoss AS 7 was replaced with JBoss EAP 6.3.0.Alpha.
• Page Composition API - An enhancement of the Portal Public API allowing to create and edit page content, i.e. add and remove portlets and layout containers. See the Page Composition API section of GateIn Documentation.
• Automatic way to update all sites at once (Portal, groups and user sites). See GTNPORTAL-3328 and Working with Templates chapter of GateIn documentation.
• Impersonation - Portal administrator can now view another user's customized dashboard/pages without logging out. See GTNPORTAL-2662 and the Impersonation chapter of GateIn documentation.
• Experimental support for large third party JavaScript frameworks, such as Dojo. See Native AMD Modules in GateIn documentation.
• Public Render Parameters can be now propagated to a different page. See GTNPORTAL-3369.
• Navigation nodes can be defined with external links. See GTNPORTAL-2428 and the specification if the feature: Custom Navigaton Node Properties
• Login validation and accounts expiration can be additionally customized. See GTNPORTAL-3402.
• Pages can be completely hidden using check-box and date-control, see GTNPORTAL-3370.
• General markup review and cleanup and greater alignment and consistency with W3C validation.
• All features, bug fixes and minor enhancements are listed in GateIn 3.8.0.Beta01 Release Notes.

Download here to try it out. Your feedback is welcome in GateIn Forums. Please report issues in GateIn Jira.

From 13 to 16 November there will be a big event in Brazil which will discuss interaction design, the "Interaction South America" conference. This is the biggest event of Interaction Design in South America, and will feature big names in the field such as Bill Buxton (Principal Researcher at Microsoft Research) and Louis Rosenfeld (co-author of Information Architecture for the World Wide Web), the bible of Information Architecture.

This year I will talk about interaction design at the conference, presenting the proposal of redesign I did for GateIn.

My idea is not to talk only about the redesign process and its phases, but also about my experience collaborating to an open source project, something I'd never done before.

I will also talk about the Red Hat Common User Experience Initiative. For the ones who are not familiar with it, it's a project that aims to provide a common design for the Red Hat products. I'm contributing to it indirectly as I am using the proposed elements in a project, and suggesting new elements that were not designed. A console that uses the elements proposed by RCUE should look like the image below:

So that is basically what I intend to cover at the conference. I'll write another post soon talking about how was it. Hopefully we see again soon

With the release of GateIn 3.6.0.Final we introduced some new CDI scopes to ease its use within a portlet.  This second blog on CDI scopes for GateIn, will cover @PortletRedisplayScoped. This scope can be used with GenericPortlets, Portlet Filters, or JSF Portlets.

This scope is retained beyond a single Portlet Request lifecycle to be retrieved for all subsequent Render Requests that don't involve an Action or Event. The Beans in this scope are destroyed subsequent Action or Event requests, enabling continual refreshing of the portlet by a user to repeatedly display the same exact content as the Bean data will not be re generated for each Render. The following table illustrates when the context for the scope is activated (A), destroyed (X), or when its already present (P):

An important distinction is that any Beans created within the scope context as part of a Portlet Action, Portlet Event or Portlet Render are not visible within a Portlet Resource call, and vice versa. Each ResourceRequest will receive a completely empty set of Beans that have been constructed, including calls to any @PostConstruct, but that have had no code executed against them.

There is one difference with how Resource Request Beans are handled as compared to @PortletLifecycleScoped, in that any Beans that are used during a Resource Request will be merged into the context of the main portlet lifecycle. What this means is that the values on a @PortletRedisplayScoped bean that was used during a Resource Request will replace the contents of the same Bean type for the next Render Request that is executed. In most cases that wouldn't be a problem, but it's a potential gotcha if you make lots of Ajax calls and suddenly wonder why the values in your Beans are all wrong the next time you Render the portlet.

To begin using the new scope, simply add the following dependency into your portlet project pom.xml:

        <dependency>
            <groupId>org.gatein.api</groupId>
            <artifactId>gatein-api</artifactId>
            <version>1.0.0.Final</version>
            <scope>provided</scope>
        </dependency>

We mark the dependency as provided since GateIn will automatically link our deployment to the latest API dependency at runtime.

With the above dependency we can then create a bean such as:

@PortletRedisplayScoped
public class LifecycleBean implements java.io.Serializable {
  ...
}

Note that we implement Serializable for our Bean, as the context is stored within the User Session, which can potentially be passivated by the container.

As far as CDI is concerned, @PortletRedisplayScoped is a bean scope like all those that it provides. This enables us to inject @RequestScoped, @ConversationScoped, @SessionScoped or @ApplicationScoped beans into a @PortletRedisplayScoped bean, or vice versa.

Hope this and the scope we covered in the previous blog will make developing CDI portlets with GateIn that much easier!

With the release of GateIn 3.6.0.Final we now have the ability to inject CDI beans directly into our portlet classes, whether they extend GenericPortlet or implement the Portlet interface, and any class that implements a Portlet Filter interface.

The injection works just the same as with any other CDI injection, with one small caveat. When deciding which Beans to inject into our portlet or filter, keep in mind that injecting a normal scoped bean, such as @SessionScoped, is fine even though there is no User Session present, because the container will simply inject a client proxy for us, but it's not possible to inject a Bean that is being produced by another Bean that doesn't have a valid context.

To explain this with an example, if we take the following portlet class:

public class BadPortlet extends GenericPortlet {
  @Inject
  private Greeting myGreeting;
}

and create a producer for it such as:

@SessionScoped
public class GreetingProducer implements Serializable {
  @Produces
  public Greeting produceGreeting(InjectionPoint point) {
    ...
  }
}

We receive a ContextNotActiveException because we're trying to produce one Bean from another Bean that is not yet, as there is no User Session during Portlet Container initialization.

When wanting to inject a produced Bean into a portlet class or filter, they need to be produced by @ApplicationScoped or @Dependent scoped Beans.

Here's an example portlet showing how we can use CDI injection:

public class MyPortlet extends GenericPortlet {
  @Inject
  MyBean bean;

  public void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException {
    PortletRequestDispatcher dispatcher = getPortletContext().getRequestDispatcher("/myPage.jsp");
    request.setAttribute("myBean", bean);
    dispatcher.include(request, response);
  }
}

In our JSP we can then access the bean with ${myBean}.

I hope that this introduction into creating CDI enabled portlets and portlet filters will make your next portlet a bit easier to use with CDI!

Gate In Device Detection and Site Redirection for performing redirection based on Use Agent has been available since version 3.5.0.Final but configuration was only possible through manual editing of a XML file, it’s modification would not affect the portal at runtime and even after restarting the server it would only be reloaded after deleting some data generated at startup. But that’s history, Gate In 3.6.0.Final introduces the “Site Redirects and Import/Export Portlet” to solve all these details for Site Redirection while also integrating the previous “Import/Export Site” portlet behavior in a more modern way, thanks to the fabulous work on the UI/UXP by Gabriel Cardoso and making use of the cool Richfaces Bootstrap Components!

You can find this portlet when logged as an Administrator under Group > Administration > Site Redirects and Import/Export on the top menu.

Configuring Site Redirects

Once on the portlet the list of available Sites is presented on the left side menu. Spaces are also present but they are not available for Redirects, only for Exporting.

Selecting a site will present the available Redirect conditions, which can be ordered by using drag and drop. These should be ordered in a way that most specific Redirects are on top (e.g.: “iOS”, “Touch”, “Mobile”).

A Redirect can be configured by clicking the “Configure” wrench icon, which shall present the following screen for its configuration:

In the top section, it is possible to toggle the redirect on or off, change it’s name and select to which site it should redirect to.

The “Conditions” section is where it is possible to define the conditions to evaluate in order to know if this redirect should be activated. These conditions are composed by valid Java regular expressions, can be checked for its presence or absence and are evaluated against the User Agent String. It is also possible to evaluate against custom defined properties (such as width, height, number of colors, etc), which should be configured at detection.jsp. See more detailed information on this at GateIn Developer Guide - Site Redirection.

At the “Node Mappings” section there’s the possibility to define where to redirect when the use is heading for a particular portal node, by either using node name matching where he’s redirected to the node with the same name or to define a custom node mapping, such as “classic/flash” redirecting to “ios/flash-not-available”. In case no mapping is defined and a node with the same name is not available (when node name mapping is enabled), the default action to perform should be defined in the unresolved nodes select.

More detailed information about how to configure redirects can be found at the User Guide.

Export a Site or Space

This same portlet allows exporting a site or space to be used in a different portal instalation or for backup purposes.

To do so, click the small arrow that shows on the right side of each site or space and click on the export option from the dropdown menu and a download of a zip containing the relevant files will start.

Import a Site

Importing a site is as easy, simply select the option to import from the left side menu and from the popup window, select the files to import (up to 5 at a time), select the desired import mode and voilá.

I am are proud to announce GateIn Portal 3.6.0.Final release.

This is the outcome of several months of hard work of all developers involved in this project. Here I would like to thank everyone who helped make this release a reality.

For the past month and after Beta02 we have been mainly focused on fixing bugs. You can see the effect in Release Notes with 79 solved issues.

All key features have already been covered when announcing Beta01 and Beta02. Therefore I would like to just mention them briefly:

• OAuth2 support
• Demo mobile site with adaptive layout
• New administration UI for managing site redirections based on device recognition
• CDI support
• New Public Navigation API
• EAP 6.1 integration
• A lot of new QuickStart examples

It is not possible to share enough details regarding all of new features in just one blog post. Therefore instead we decided to provide you with better coverage of all exciting improvements coming in GateIn Portal 3.6.0.Final. During next few weeks you can expect developers involved in the project to regularly post new articles or screencasts here. Stay tuned!

So what is comming next? We are switching focus to work on 3.7 release to follow. Let us know if there are any particular features you are interested in or you would be willing to contribute to. In parallel Julien is working on next gen architecture for GateIn 4.0.

Enjoy new GateIn 3.6.0.Final. Download and try it out while it is hot

This year was the first time that JUDCon came to Brazil. The event happened on April 19 and 20, and was the first Red Hat Latin American Developer Conference. Mark Little, who leads the JBoss engineering team gave a keynote and announced the rebranding of JBoss As as WildFly.

The JUDCon 2013:Brazil presented nearly 70 sessions and had an attendance to 340 developers. Since talks about design are rare in this kind of event, I decided to submit mine, which was approved: Designing a New User Interface for Open Source Projects. In this post you can follow a little of what was covered in the presentation.

A project without a designer

I started saying that the User Interface of an Open Source project can suffer a lot without a designer. And that's not only related to visual design, but also to usability, the quality of usage.

As an example, I shown the page of PECL, a repository for PHP Extensions. I guess they probably don't have a designer in the team... What do you think?

In the case of Gatein, some inconsistencies have been appearing over time. Do you see any reason for the login pop-up (in the left) and the login page (in the right) to be different?

In this example, we can see inconsistencies of visual design (header, left image, colors, borders) and navigation design (the option "forgot user/password" and the possibility of getting out of the dialog is only available in the popup).

But how to avoid that inconsistencies and usability problems happen?

A design process for the Web

Instead of defining everything when you are ready to code the solution, how about following a design process that divides the problem in steps? That's what Jesse James Garrett presented in his famous diagram "The elements of user experience" in the early 2000's.

He is basically saying that, after having the scope (requirements), it is needed to think about structure (flows and information architecture maps), skeleton (wireframes) and only after that go to the visual design. The next images show examples of this steps in the redesign of GateIn.

Structure: fragment of the new Information Architecture proposed for GateIn

Skeleton: Wireframe for the Portal Configuration page. The new design proposed the usage of more pages instead of pop-up dialogues.

Surface: first proposal of visual design for the redesign of Gatein.

Where to start in case of a redesign?

Ok, that's the process of design. But where to start in case of a redesign? Specifically in GateIn, we wanted to improve visual design and usability. So my first task when I joined the development team was to conduct a usability inspection. To do that, I followed the Jakob Nielsen's 10 Heuristics for User Interface Design.

The outcome of this work was a spreadsheet listing the problems found. Usability inspection: fragment of the list with the usability problems found.

Usability inspection: fragment of the list with the usability problems found.

Based on that, we could prioritize which pages to redesign first. The first one was the Portal Configuration page. After proposing a new Information Architecture for the portal and a new wireframe for the page, we went to the implementation of it in HTML and CSS.

Speeding up with Twitter Bootstrap

To accelerate the implementation, we decided to test Twitter Bootstrap, a front-end framework to speed up the development. The first implementation was done based on the wireframe, without having the visual design. We used only the HTML structure suggested by Bootstrap, without adding any line of CSS. The result can be seen in the next image.

Our HTML with only CSS from Twitter Bootstrap.

Without any customized CSS, Twitter Bootstrap already provides a good header, nice buttons, a solid structure for the sidebar and well-designed forms, including tables. By adding a customized CSS with only 250 lines, we could achieve the result of the next image.

It is interesting to say that, without Twitter Bootstrap, this design would need much more lines and time to be implemented. It needed only around 15 hours to look like this.

Although the interface was OK, we wanted something more special for GateIn. Based on this HTML prototype, we refined the visual design and reached the following result:

The redesigned pages were also implemented in HTML + CSS + jQuery, and can be seen at:

• https://statichtml-theute.rhcloud.com/cardosogabriel/gatein-client/site-config.html
• https://statichtml-theute.rhcloud.com/cardosogabriel/gatein-client/site-redirects.html
• https://statichtml-theute.rhcloud.com/cardosogabriel/gatein-client/space-config.html
• https://statichtml-theute.rhcloud.com/cardosogabriel/gatein-client/index.html

A mobile demo with Responsive Web Design

Since we planned on launching site redirects support for GateIn 3.6, we decided to offer a mobile demo with a design that works well in mobile devices.

Mobile demo in a smaller screen.

Before being integrated to the project, it was implemented in HTML + CSS + jQuery, using Twitter Bootstrap too. The solution can be seen here: http://statichtml-theute.rhcloud.com/cardosogabriel/gatein-client/responsive/index-mobile.html. Try to reduce and increase the size of the window, or access it in different devices.

To make the original design responsive, I focused on two details:

Fluid widths and distances in percentage (%)

If you want to make the design fit the screen, you need to convert the widths, margins and paddings to "%" instead of "px". Here is an example:

This makes the container (width of the page) fit 95% of the width of the device, instead of having a fixed width that would not fit all devices.

Break points

This is the magic of the Responsive Web Design. With break points you can declare specific CSS for specific dimensions. In the case of the Mobile Demo, I wanted the container to fit 95% of the screen for most of the cases. However, for smaller widths, I wanted it to occupy 100%, and for bigger widths, I wanted it to occupy 1170px as maximum. To do that, you just need to do declarations like these:

Conclusion

With this talk I wanted to show the design process that comes from the requirements until the HTML implementation. The full presentation can be seen at: http://www.slideshare.net/gabrielcardoso9/designing-a-new-user-interface-for-open-source-projects

GateIn was an excellent showcase, since its redesign followed the steps presented by Garrett in its diagram. Twitter Bootstrap provided nice UI components reduced significantly the time required to implement the solutions. Having applied the Responsive Web Design to the interface was exciting and made it look beautiful in many different devices.

I hope you have learnt something from this post. Stay tuned to the next GateIn releases. More design news are coming

GateIn 4.0

GateIn 3.0 was released almost 3 years ago as the result of the collaboration of the eXo Platform and Red Hat team. The team worked then on a serie of improvements for 3 years until the recent GateIn 3.5: the project improved and gained maturity among releases, specially with the recent 3.5 release. The main goal of GateIn 4.0 is to rework the portal engine: the current engine has aged enough for being replaced by a more modern engine for providing better everything.

This project is important to me: I left Red Hat for eXo Platform in 2008 and I was working on the future JBoss Portal 3.0 at this moment and I left some unfinished ideas. During the GateIn collaboration other ideas came, some were implemented in GateIn, some could not due to the architecture. 4.0 is for me the opportunity to work this out.

Juzu

The Juzu Web framework will be used for rebuilding the aggregation engine: a portal before all is a web application and the idea is to let Juzu focus on the web part and leave to the GateIn engine focus on being a set of controllers (in the MVC way) for aggregating content or editing it.

Juzu was started a year ago, it provides since version 0.6 a servlet mode that makes it able to deliver web applications in addition of portlet applications. Of course it embeds some part of GateIn already in it, for instance the Juzu route controller is an improvement of the route controller of GateIn.

Juzu relies on the JSR-330 specification for wiring components and provides therefore a standard programming model. It integrates with Annotation Processing for doing wonderful things with Java (yes we not planning to rewrite GateIn in another language).

The project

The main focus is to rewrite is the portal engine with the serving of portal pages based on a better model and the native portal applications: the page edition for example. The scope is well defined and is defined in the In Place Editing specification . It describes an evolution of the current GateIn model written by Benjamin Paillereau, his great work is the essence of the feedback provided by many customers, integrators and other users.

A key part of the technical aspect is the aggregation engine: it will be based on the big pipe technology for providing increased performances and better latency for page rendering. The portal will also push to the client the stale portlets: for example you define a cache timeout of 1 minute for a portlet will result in GateIn updating the portlet fragment every minute.

Beside this we are have other goals (not extensive)

• Better usability and configuration for providing a better experience
• 4.0 will give you the possiblity to embed GateIn with an in memory implementation that provides a fast and stateless portal for testing purposes
• Rebase the skinning and layout on Twitter Bootstrap

The road

GateIn 4.0 will not be the next GateIn release right away, we have plans to provide additional GateIn 3.x releases that the team is currently working on. Nevertheless GateIn 4.0 development has started recently, you can follow the development on the gatein-dev mailing list "GateIn 4.0.0" thread. I bootstrapped this work a few weeks ago and I welcome anyone wanting to contribute to join us on the list.

Open source and open minded.