I'm working on the Admin's UI and had some ideas I would like to share with you to see if they are feasible so I can keep going in this line. The main idea is to have a particular interface for the Administration where both Admin and Content Manager can perform their tasks.

The first big change is to separate the admin's and portal's interface. So when the Admin enters, he doesn't see the homepage anymore, but a Admin interface, wich is more useful to him. To see the Portal, he needs to click  "View Portal" under "Classic Portal" at the top bar. By putting that selector at the top bar I'm suggesting that the changes made in the Admin are only for the "Classic Portal". If he wants to make changes related to another portal, he needs to select this portal in the top bar at first. This way we reduce the information load in some pages (e.g. Page Management) and make him focused in doing one Portal management at a time.

Another important change is the replacement of some modal boxes (pop-ups) to pages. Pages like Portal's Config  works better in a page because in this new proposal because user does not loose context. Also the required fields are easily visible (since they are not spread in different tabs) and we solve the problem that sometimes a feedback talks about a required field that is not visible at that time because it is in another tab.

The mockup makes easier to the user to find out where he is since a big title is displayed and the sidebar presents the opened link as active. The title and the buttons Edit page and Edit Layout (top right) are fixed at the top and always visible. In pages with forms where user needs to save / cancel changes, these buttons should be always visible in a fixed bottom.

Some action were regrouped at the top bar. At the side of the Portal name is possible to Add a New Portal / Add a New Page. Links like Account Info and Sign Out were put under the username. Change language / change skin were put under the settings icon so the Logo can be used as a link to the homepage.

My proposed sidebar organization can be shown in the Admin's Information Architecture Blueprint and follows some ideas proposed previously by Thomas. I basically propose the following groups:

- Portal: old "Edit Portal's Config"  + "Edit Layout" + new "Redirects"

- Pages & Navigation: old "Page Management" + "Edit Navigation" related to Portal, Groups and Dashboard

- Applications: same as "Application Registry"

- Users and Groups: old "New Staff" + "Users and groups management"

- WSRP: same

- More: Service Management + Site Import/Export + New features…

User pages like Homepage, Sitemap, Sample-Ext Page, My Link and Dashboard are presented only in the portal (view Portal).

Hi Gabriel,

I've got some feedbacks about your mockups. There are interesting but some things can be improved IMO, to make the interface clearer for users.

Here is about your first screen :

* In the navigation bar, there is quite a lot of things… I don't think "delete a portal" feature has his place in this menu.

* "Portal Name", "Label", "Description" are providing similar sense. It should be more precise to help users to understand differences in form fields.

* required fields are highlighted with asterisks. I think it's stressing any user in any form doing stuff like that. The solution is to use a placeholder in optionnal fields. (It's an uxp rule)

* about "save" and "cancel" actions, it's true that depends if you are Mac user or Windows user, but we should stay consistent everywhere. For now we align them on the right !

* buttons for "edit page" or "edit layout" are not clear. I think labels might be necessary...

Good idea for modal boxes. I like it !

About the navigation bar, I think it can be improved by :

* avoid using redundancy in key actions : in "Add New Portal" and "Add New Page", "Add New" add some useless noise

* root and options might be merged.

Feel free to contact me if you want to discuss.

Thanks Thomas!

I do believe we should present the Admin's page to the Admin at first if the managing tasks are more often than browsing the site. But you guys are more familiar with the product to tell me about the Admin's goals or we can do a quick research.

I'll think about a solution for the Portal selection to remove the inconsistency of some actions being cross-portal and also think about a solution for multiple permissions to edit.

Hi Stévan. Nice to have a feedback from a designer. I agree with some feedback but I'm not sure about the following topics:

- Portal selection: I'll need to think about another solution for the portal selection anyway but I'm curious to know why "Delete portal" should not be there.

- Required fields: I've read that optional fields should be pointed when the screen presents less optional fields than required ones (not this case) and I've been seeing * as a stronger pattern. Do you have the source of this UX rule?

- Edit page + Edit layout: Those icons are not final (will be refined) and the idea is to provide a tooltip for those actions. I don't want to add more text and pollute that area so I prefer that users explore the button and learn what they mean, following the Alan Cooper's advice to optimize to intermediates.

Thanks

For the new Admin UI, I believe it would be beneficial to remove the ability to edit page nodes for the Admin pages.

With a move to a more modular Admin UI, whereby modules are auto discovered and added to UI, I don't feel that there is a need to support editing of those pages.  Providing the ability to edit the pages would hinder the goal of making it more structured under specific headings.

Besides, how often is someone going to be modifying the Admin UI?

Ken

Hi Gabriel,

the biggest issue I have with your mockup is that it mixes two kind of roles which don't have the same meaning

• publisher (as in WCM / EPPSP) which cares about how the portal is used to present content or portlets
• administrator (as technical person) that cares about how the portal is configured and focus on low level administration

Let's take an example of the portal config:

• publisher cares about the skin, the portal display name, etc...
• administrator cares about low level concern such as "keep alive session" for instance

Mixing the two kind of concern in a single administration screen creates confusion and also is error prone as one role may change a portion of the configuration he should never change.

(I may have some other concerns later)

my actually biggest issue is that you talk about removing popup (which are actually sometimes bad) and they should not removed all the time, which means that my answer "yes and no":

• technical administrator need what you have designed: a centralized view of the administration
• publisher administrator (or content administrator as you say): they often need to configure something they are actually seing or using

Hence what you have designed certainly makes sense for a centralized administration, however removing contextual administration (popup) would certainly be a regression in term of use case of administration. However I think that the current contextual admin should be simplified. For instance:

• configuring "keep session alive" does not make sense
• some contextual admin is heavy weight and generates too much config or wrong config

I will try to explain my point of view for :

• "Delete Portal" in Portal selection :

Deleting a portal might be a critical action from the user but also not oftenly used, so it must not be too easy to access IMO. My second point, is that you put at the same level "navigation" and "action" and it can add some confusion for the user.

• Required fields :

I've read this article. I understand your idea, but who will be users of these Admin features ? I think it will be premium users (Admins or Content Managers), so at least, I think you can remove the part "* Required fields" (and remove some noise here ).

• Edit page + Edit layout :

Probably I didn't correctly understand the meaning of these features and why there are directly put at the same level as Portal Administration ?

Do they are relative to edit one particular page/layout ? In this case, they are key features of Portal IMO, so a Content Manager user should use them oftenly and he must find these features very quickly and easily, without having to learn the UI no ?

Perhaps I didn't understand clearly what is behind these buttons, can you describe a little ?

Good idea to apply Alan Cooper's advices to optimize UI for intermediates users, but you should find good icons ! good luck it will not be easy ;-) !

Thanks for your reply Gabriel !

Hi people.

After your comments, I ended up with other wireframes for the GateIn's admin. I'll try to explain my point of view for every comment.

Julien's Viet concern about mixing the two kind of roles (Admin / Content Manager) in the same screen is critical for the evolution of the concept. By taking a look at the current Admin it's possible to see that the Admin can access everything the Publisher does. So the mockups I posted were about the Admin's view. As Thomas said, the idea is to present to the Publisher only the sections he can edit in the same interface. My reason to not offer a different interface for the Content Manager is that he performs the same tasks as a Admin can perform but without some privileges. So in cases like that, it's recommended to design for the Admin and optimize for the Content Manager (only showing to him the areas he can Edit). If I understood well, the Admin will stay more at the Admin's interface and the Publisher will be both in the Admin's interface (e.g to manage users) and in the Portal's interface (to edit portlets / content in pages) so that might work. In Admin's interface, the Publisher would see something like the attached image.

And the New Admin's Information Architecture Blueprint based on the permissions currently existent. The blue man is the Admin and the green one is the Content Manager:

Ken is not sure if the Admin should be able to edit page nodes in the Admin's pages. If we believe that our admin is good enough at a level to not require any customization, so I agree with him. Otherwise, maybe we should let them edit their Administration area. Thoughts?

About the idea of minimizing the page modals, I agree that those modal boxes are useful in many cases (but not in all cases that it is currently used). So I intent to keep some pop-ups (e.g. Change Language) and replace the complex ones by pages that don't need to keep the context.

I also tried to make more explicit which operations are specific to a portal (under Classic) and what are accross portals (at the bottom). Unfortunatelly I didn't find a better place than the top bar to put that selector and I believe it's not gonna be confusing with the label in the sidebar.

Now it's also possible to give permission to edit for multiple users. Username / Settings were merged as Stévan suggested.

To reduce the number of fields of the Portal creation / settings, I removed the fields label / description. I believe the Admin will survive without them by giving meaningful titles for their Portals. Please let me know if they are crucial

I also put "Session" and "Info bar" under the folded section "Advanced Properties" that are only available to the Admin.

quickly replying:

one thing you don't get is that publishers don't go in a centralized admin to edit a portion of the configuration they need.

they use contextual configuration of the part of the related entity they are viewing: for instance they are viewing a page they click on a button and they can configure what it is relevant to them without changing the current navigation. This configuration only show the information they need to do their work.

Hence the existing popups that you want to remove (for some unknown reason) and shove in the centralized configuration is a fundamental mistake you are doing.

However this does not preclude to have a centralized view with everything as view plugin as thomas suggested and as you are trying to leverage.

Hi Julien. I think I got your point and we are saying the same thing. My idea is not to remove all pop-ups neither to make the Content Manager try to edit content / portlets from a centralized admin but to make some pop-ups as pages (e.g. Portal's config) when context is not necessary and offer the Admin's interface when he needs to manage the Portal (not configure a page) (e.g. to manage users and groups). The scenario I thought to the Content Manager is the following:

1) Publisher logs in the Portal and sees the homepage.

- The top bar shows that he is seeing Classic and he can change the portal.

- Manage Portal takes to the admin interface (Administration and Organization…)

- The menu item "Group" was removed, replaced by My Pages (current User's Pages under Group). Maybe it could be integrated to the Portal NavBar? Just a proposal...

- Site editor was replaced by Add Page and the button Edit Page

2) Publisher decides to edit the content, so it clicks the button Edit page (top bar)

- Buttons Save / Cancel are prominent

- Page Editor could be integrated to the page. That would be better for users who don't have large screens (so the pop up does not stay in front of the content).

3) He saves the changes and decides to edit some portal information / users so click in Manage Portal.

This is clearer now thanks for clarifying that.

I think that Thomas initial idea about the centralized admin is great, however I think also that the current work you are doing is too much preliminary as we have not yet time to discuss about the evolution of the UI at an high level.

We all want to make the UI evolve to handle new features and the current work you are doing cares about the existing without the forthcoming evolutions (explaining why it is preliminary): what you are describing in 2/ will be deprecated as we want to change the UI ("we" as the idea we put in the PRD agreement).

I think both parties (exo and RHT) have strong opinion on UI (and RHT more since you joined the team) and we have a product to build together. It would make sense to me that we spend time together to discuss about this, from eXo side probably me (involved at the UI and technical level) and Stevan (invovled at the UI level) at least.

However this does not involve all the admin UI:

For instance the organization service user interface is not under my consideration as it is decoupled from the portal UI. It's certainly something you could look at that is much less impacted by the forthcoming PRD stuff. As a side note: I started to work on a UI prototype using Juzu Web Framework, the goal is not to be the next GateIn organization management portlet but more a sample portlet using Juzu to prototype advanced UI techniques (JS / CSS) and also provide a powerful organization service UI (but at the expense of not being the most intuitive for noob). If you want to talk about this in another thread, don't hesitate.