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:
Users get lost and don’t know where they are inside the product menu.
There are many possible choices, up to 75 di"erent items in the menu, which make very di#cult to find whatever the user is looking for and make slow and frustrating the learning curve of the product use.There are many di"erent navigation levels. The worst scenario is to navigate through 7 di"erent levels to arrive to the desired place (found inside the LDAP options inside the virtual instances settings while trying to add a LDAP Server).
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:
There are too many elements and too many levels inside the product menu. It can be useful to have it all together but that makes very di#cult to look for what the users need and also make them feel lost inside all the options and a very frustrating learning curve to know how to use the product.
Many customers remove the product menu to implement its own, even when it is trickier than expected. In most cases, this is because the product menu is not desired to be shown for non- administrator users, and right now it appears for all logged in users.
It is dificult to remove options from the product menu.
Users don’t want to see what they don’t use. The product menu is not ordered in a cohesive way, there is not a recent, usage or alphabetical order. Having the configuration splitted up makes the user to have to visit some di"erent places to find what they are looking for. The possibility to hide / show elements in an accessible and easy way would make the product menu much more usable.
It is important to solve navigation among sites and navigation among pages.
A good search options is a must (indexing inside the menu, the forms and the content).The user profile needs to be apart (or even not making the regular user to access their apps through the product menu).
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
Site Logo. Quick Access to the current Site Home
Search
Site Builder (icon pending to be changed to something more related with construction)
Content
Memberships
Sites
Most recent or Most used
Quick Access to Control Panel (if the administrator has the proper permissions)
User Menu
B.Panel triggered by the icon sidebar
Section title and trigger to open and close the panel. It can be more than one section inside the icon group
Elements inside the section. A scrollable panel would be possible if there are too many elements to be shown.
Selected element
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.
Logo - About this liferay
Control Panel
Search bar
Most Recent
Help
User Menu
We would like to provide the administration user with a search functionality for administration to address all applications through a search bar.
A Help section to unify where the user can find help. A getting started guide, with tips, videos and a walking tour around the control panel, the documentation, and links to the community and resources. Even with the possibility to report bugs.
An About this Liferay section where to find the version in which you are, and if there are any new versions available. Your license and relevant information about your installation.
A most used / recent elements section to have a quick access to the most used activities.
The access to Site Admin and Control Panel could be done through the login inside the current main sites or through a different URL only for administration, to make clear the difference between the regular user and the administrator.
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.