Administration Experience

In collaboration with my team for Liferay · 2018 (Not developed)

This research was conducted to propose and implement a new navigation possibility towards new releases that can improve the way to interact with the interface and tho make easier for the administration users to achieve their goals within Liferay. To do that, we run interviews, work in a new information architecture and wireframe possibilities to get to the final version of the administration experience.  

1.The challenge

After several attempts to change the product administration navigation within versions, ending with the current product menu, we have finally understood that there is not perfect solution that fits for all of our customers. For those who don’t know what the product menu is, the image below illustrate what I am talking about.

A few weeks ago we started gathering feedback from employees, partners and customers to determine how we could better serve the administration needs. Our goal was to do the research and design work during the 7.2 cycle and implement it for 7.3.

For those who cannot wait. We concluded that Liferay Portal/DXP needs to provide two things:

1. A default administration solution, which will allow administering everything in the platform out of the box. This solution will be targeted towards high level administrators. In this solution we will add back the concept of a Control Panel that is separated from the regular sites. We will keep the product menu, but will be focused solely on Site Administration. The user menu will be converted to a dropdown when clicking the user name or avatar.

2. The ability to easily create custom administration experiences. This will allow the developers of a Liferay-based solution to build the administration that makes most sense for their specific Personas. Examples could be a site dedicated to administration for Store Admins in a commerce scenario, or allowing administering users within a specific site, ... To facilitate this, the out of the box administration applications will be prepared to be reusable within any theme and site. We will also provide easier ways to add those applications where desired programmatically/through configuration. 

This is, of course, just a summary. Keep reading to learn more about the research and the final solution proposed for 7.3. To reach this conclusion we went through a deep research, through qualitative interviews to find pain points and patterns to solve through design.

Today we want to share the process and first results. Any suggestion and feedback will be very welcome to keep improving the product towards new releases! It is important to understand that these proposals are not going to be ready for the next 7.2 release of the product. It is important to highlight that all the wireframes showed in this document are not final solutions, but proposals that have not been visually refined.

2.The Research

2.1 Benchmarket

A benchmarket consists of a comparative research using similar products from direct and indirect competitors to look for di"erent approaches and solutions they may use. Some new ideas came out through this method.  

2.2 Evolution of the product menu

It is very important to understand the evolution and why some detitions were made at that point to try not to make again the same mistakes. For this, interviews to di"erent stakeholders, reading through JIRA and reviewing past designs has been relevant in the process.

2.3 Interviews

We run 10 interviews. We asked people working on Support, Engineering and Marketing from Spain and US. We also talked to Product Managers and the Commerce team which was already dealing with the current product menu and modifying it because it didn’t fit their needs, so the perfect “customer” to extract information from. If you are interested in digging more deeply into the data, this document is the summary with links to the evolution of the information architecture among versions and the transcript of all the interviews and meetings ..

2.4 Affinity Diagram

To extract the patterns and ideas from the interviews we used an a#nity diagram. Through this method we could visually order and group all pain points and suggestions, and count votes on them to see which ones were more repeated by our interviewees.

We detected some new problems and reinforced those theories that we already had from the past and also some new approaches.

From the interviews and previous reports we discovered that:



Other pain points detected inside the product menu were, according to the interviews: search, navigation, permissions, notifications, help, documentation, taxonomy, settings and information architecture. An some other relevant problems were related to navigation among sites and the back navigation.

2.5 Highlights

From the interviews we could extract relevant highlights:

2.6 User personas

User personas were created to test the portal for di"erent roles in the past. We used these main personas to test the out-of the box or by default administration experience and detect if some possibility was not covered by the proposal.

3.Information Architecture

After the research process, we started looking for a new information architecture to organize all items in a way to they would be easy to find and usable.

We decided to split up the administration experience for site administrators and higher level administrators. This means that System and Virtual Instances would have its own independent control panel interface, and the site administration would remain within the site itself. Making a clear role and scope differentiation.

3.1 Site administration

If you are curious about the new information architecture resultant from the analyse, take a look at the image below.

Changes for Site Administration:

A default administration experience for site administration will be provided in the future. A possibility could be to have di"erent administration experience approaches per Liferay installation type: community, site or intranet at first. Always having in mind that our main and ultimate goal is making the menu easy to remove to build custom administration experiences for users by IT.

The following image shows a wireframe of the product menu we would like to achieve for a site administrator, supposing that the site to be administered is liferay.com (it would apply the same for any other case). As you can see there is an icon sidebar at the left, with all the sections available for the site administrator.

The icon sidebar create a new hierarchy level in an easy visual and non invasive way that allow the triggered panel to be organized in smaller groups with all the options available. Because of the controlled number of icons, it should be easy for the user to remember the meaning and learn how to use the interface.

3.1 Site administration

3.2 Control Panel Administration

4.Wireframes

4.1 Site Administration

A. Icon Sidebar

B.Panel triggered by the icon sidebar

The icon bar is composed by: search, site builder, content, users and sites. At the bottom the user menu and a quick access to the control panel and the most used features.

Options inside the menu will be configurable to show or hide the elements that the users might need.

Configuration is being divided, moving each setting to the appropriate place inside the application to avoid that users have to look in different places for the setting they are looking for.

The search option has a fundamental role, helping the users to find what they are looking for in an easy and accessible way. A indexed search bar to find information inside the menu, the forms or even the content, with autocomplete feature and showing the path to teach the users where they can find each element.

The visualization of the icon bar may vary according to the permissions of the administrators. The plan is to build a configuration mode to hide/ show options available from the configuration to provide the administration user with the power to decide whether applications is going to view in the panel.

4.2Control Panel administration

Virtual instances will include: users, sites, virtual instance details and security. On the other hand, System will include: virtual instances, applications, server administration, system details, content and data settings, platform and security.

For those Virtual Instances that are not the main instance and don’t have access to the System Administration, the control panel will be similar but without the section of system.

What happens with those who already like the product menu? We need to provide the option to keep seeing Control Panel and Site admin in one place. A direct access to the control panel is needed in case the user is a super admin and has access to both control panel and site administration. There could also be a most recently used features.

5.Custom Administration Experiences

Facilitate the creation of Custom Administration experiences for special solutions, as well as creating any other type of site, using widgets and fragments to build a customize administration experience that fulfill the specific needs of the users. The next site can be the administration experience for a blog content reviewer, looking as a dashboard. Where administrators can view and edit all the information they need.

In the future, these administration experiences could allow the user to build custom experiences as Commerce. But for the moment, these more complex options need to be builded by removing the current administration and creating one from scratch. We want to facilitate the way to uninstall and remove the current administration, so as to make easier and more accurate the solution for all types of administrators.

Previous Project

Sidebars

Next Project

System Settings