eZ Community » Forums » Discussions » Administration interface refresh,...
expandshrink

Friday 11 December 2009 4:00:49 pm - 58 replies

» Read full blog post

Introduction

eZ Publish 4.3 will take a big step towards refreshing the administration interface. A first blog post was made here (comments by the bottom of the page) , have a look at it first!
The second round is presented below, having integrated the feedback from the first round.

Wednesday 13 January 2010 5:04:01 pm

@ar good to hear that tabs for object might be back and the buttons near where they belong too.

Some further proposals:

  • if the buttons to add/move children are moved to a toolbar in the children box, that leaves more room in the current-object toolbar. Space that can be used to display more links that are only currently available on the context-menu and that many people skip simply because the context-menu is a bit too hidden
  • move the 'buttons toolbars' at the top of the box they belong to, not at the bottom (rationale: less scrolling and looks more like menus/toolabrs in desktop apps, where toolbars are at top and status bars at bottom)
  • add the triangular icon next to the big object-being-shown icon and use it as item that pops-up the context menu when clicked upon: this adds consistency with the context menu shown for children and is also more intuitive than clicking on the current obj icon
  • for children items, use an icon for 'visible'/'hidden': less visual clutter for an info that is boolean (the same is true also in other places of the gui)

Last but not least: a completely subversive idea: split the page in 3 vertical areas, left to right: 'node tree', 'children of current item', 'preview of selected item'

The advantage are:

  • it's a layout used by most filesystem-navigaton intefaces (win >= xp, macos)
  • makes it easier to access children items without scrolling past current object preview (when current item is not marked as folder in left menu)
  • screens tend to be wider nowadays
  • it reinforces the idea that what you are seeing for current object is in fact a 'preview', and that to get full details you should go to object-editing mode

Wednesday 20 January 2010 9:20:44 am

Have updated the extension version of the design. Install instructions: http://bit.ly/8auyd3

Wednesday 20 January 2010 5:31:21 pm

Hi,

For the average content editor the admin interface is still too cluttered, and the relevant info (new and updated content, new users, etc.) can not be accessed easily. We are working on a dashboard ('portal' extension) for the homepage of the admin interface using Yahoo YUI 3 (see http://developer.yahoo.com/yui/3/examples/dd/portal-drag_source.html ). For an image preview of this functionality in ezp 4.2, see: http://ezdashboard.googlecode.com/files/portal.png

The alpha version is available at: http://code.google.com/p/ezdashboard/

(svn checkout http://ezdashboard.googlecode.com/svn/trunk/ ezdashboard-read-only)

Modified on Wednesday 20 January 2010 5:32:15 pm by S V

Wednesday 20 January 2010 9:25:56 pm

Hi André,

Since I urged you to check out my latest commits, I guess I have to check out yours as well. happy.gif Emoticon

Contrary to some people, i love the new node details tabs, and hope they are here to stay. To me, they are the single, greatest improvement to the admin interface. Still, I would ask that you remember to keep the the functionality in the current admin which allows you to hide all the details, which makes for smoother browsing of the content structure. This means that there should be some way to expand/collapse the details alltogether.

Regarding the resizable left column, I think you should make it possible to drag/resize all along the right hand side. Also, the icon in the lower, right corner kind of indicates that the box can be resized both in height and width, which is not the case (and wouldn't make much sense, either). I'm thinking something like this, but vertical: http://www.itsavesyou.com/TextArea_Resizer_example.htm

Allthough I assume that there will be some theme changes before the new design is released, I think that the current version might already be better than the old one as far as esthetics go, and I ask you to tread lightly when adding colors. Making the design themable (and easy to create themes for, perhaps as separate design extensions) might be a good idea.

I would say that the drag-and-drop ordering of sub items, as well as entire subtrees in the left column, is a must. To me, it makes sense that their position is saved upon dropping, and not upon clicking a "Set" button. Even with the current interface, our clients are having trouble understanding that they should click the "Set" button after having done sorting changes.

What I think the interface still lacks (this might be improved in the "theming fase", though) is a general focus on the more important elements of any given interface. For instance, when editing an object, the "Send for publishing" button blends in with all the other buttons. In my opionon, it could be bigger, and perhaps even have a separate color (orange?) making it stand out (love the fullscreen editing, BTW).

That's all for now. Continue to dazzle us! blunk.gif Emoticon

Monday 25 January 2010 7:16:35 pm

Hi there.

I'm playing a bit with this new admin interface. I tried the new drag & drop functionality to order by priority but i don't really know if i like it happy.gif Emoticon.

I found a bit annoying that negative values are used. I mean, if you have three folders with priority 1, 2 and 3, and then you use drag and drop to reorder, priorities are changed to -990, -980, -970.

Is there any reason for usign this negative values? We always use positive for setting priorities but maybe most of you use negative for that...

Best regards.

Modified on Monday 25 January 2010 7:17:10 pm by Carlos Revillo

Wednesday 27 January 2010 8:10:13 pm

Hi,

I've just tested the current SVN version of the design admin2, it looks nicer and nicer day after day happy.gif Emoticon I have just some notes on tab ui on content/view :

  1. it would be nice to be able to choose which tabs should appear or not. For instance, on most sites we do, the object states are not used so this tab is useless so an easy way to remove/hide (INI settings ?) would be interesting !
  2. I find also a bit weird that the Details tab is the second tab. IMHO the best order for me is : Preview, Translations (if there are several languages), Locations, Details, Relations, Object states. But again a bunch of INI settings would be interesting to be able to easily change this order depending on the project
  3. On the top of the tabs, there is also a part about the node id and the object id. This part is only useful to developers and should be removed as it is also available in the details tab.

Cheers

Thursday 28 January 2010 2:54:40 pm

@Eirik: Most of the points you mention are now more or less implemented or are about to be implemented.

@Carlos: Use of negative priority is a way to make sure objects stay on top when priority is sorted ascending.

@Damien: There is no ini setting for this, I almost implemented it. But since I have never seen that many extensions or sites changing how these worked I spent the time on other things features instead. So changing it is currently done the same way as before overriding window_controls.tpl and windows.tpl (if you want to add tabs).
About point #3, yes this is only useful to developers, and there where several developers that asked for it as well to avoid having to make that extra click for something they usually need. Keep / Remove?..

Modified on Thursday 28 January 2010 2:58:23 pm by André R

Thursday 28 January 2010 3:25:18 pm

About point #3, yes this is only useful to developers, and there where several developers that asked for it as well to avoid having to make that extra click for something they usually need. Keep / Remove?..

At the eZ Winter Conf (and before I think), I've heard that the new admin interface should be centered on the editor's needs. Node ids and content object ids are far from the editors needs, don't you think ? The more the interface is cleaned from technical terms the better it will be !

Thursday 28 January 2010 8:43:33 pm

@Andre: I see the reason why negative priorities, but knowing some our customers i'm sure they will be surprised about this negative values. What about convert this text inputs to hidden inputs only if javascript is enabled and maybe tell the editors to use drag & drop to sort in that case? if javascript is not enabled then the inputs could still be text and it will work as before.

Editors doesn't matter about priority value. They only need to have something before something more or things like that happy.gif Emoticon.

Other idea it's about class editing. It's very nice to have the ability of moving attrs without needing to refresh page, but when you have classes with lot of attributes you have to scroll much to find them.

My idea is to show the users only the name, identifier and maybe it the attr is searchable or things like that, but don't show them the inputs to configure the attribute. Those inputs will still be there but it will be in some hidden div that will be visible when the user click an icon or the name of the attr they want to check.

In my experience, when you define a class, rarely you modify their attributes. You can probably add or delete, but rarely modify some of them. But, in the other hand, it's hard to remember the identifier or the id of the attribute. Implementing this open/close feature we'll don't need to do some scrolls.

Hope you understand my poor english, btw.

Best Regards.

Saturday 30 January 2010 8:23:27 pm

This new admin interface is not answer to primary problem. I am not impressed in any way.. Ok, new color scheme looks modern, loads faster but that is all we have here...

Lets look and simple everyday tasks

- entering new article: how many clicks is needed before you can even start entering content (you need to expand structure tree, find your target location, wait for it to loads middle of the page then choose from Create here menu class type, then click Create here

- second task: entering new content and want to preview it. Where to click - main buttons available are Publish, Store Draft, Discard draft. Where is Preview? Nowhere. It is in the left sidebar as "View". View what? Stored draft or this copy I am currenty editing? Confusing, confusing

I was last two days present on presentations of CMS solutions for 4 big projects (here in Croatia). I may say, most of home-build CMS-es from teams of 3 or 4 developers have much, much more user friendly administration interfaces... focused on daily content management tasks...

General opinion of panel of about 10 web users watching live demos is that eZPublish is the worst of them and I must agree.

So guys, you need to redesign admin interface not only by changing colors and little layout changes - you need redesign it from the scratch.

Friday 05 February 2010 11:10:20 am

I don't know if it's too late to add some changes but I take my chance happy.gif Emoticon

I recently add to "teach" a client about previewing content in FO with eZ Publish and they had to use it a lot. I had some bad feedback about that :

  • The preview mode is only available in "edit mode"
  • When in preview mode you can only back to "edit" or "publish" no way to go back to content structure quickly

I think that this feature is really great & usefull and must be pushed forward.

It is possible that when browsing content structure there is a preview button near "edit", "remove", ...

And to work a bit on the preview interface.

What do you think ?

Friday 05 February 2010 4:11:35 pm

I'ts not hard to feel the frustration within some of the developers here. Adding sliding functions, tabs, drag-n-drop and different colors on buttons are not the solution to our working day problems. (I know it's not for this phase, I'm just saying it's not hard to understand it.)

I'm worried about my future as a developer clicking around in the this user-friendly "admin" interface. I want none of the sliding effects. I want raw hardcore data in a developer-friendy way. I want statistics and information about the system. Answers to question that I get when I develop templates and php-code. It's not user-friendly and nor should it be.

I'm beginning to sense a strong need for two different view modes, or maybe even two different siteaccesses:

* editor (maxium user-friendly, less is more) and an,
* admin (data, id's, identifiers, numbers, statistics, you name it, the more the merrier)

And what about the front-end editing?

Superfriendly front-end and superfriendly back-end? What is you plan here? Why two places?

I may sound negative about this but I'm not. I like this discussion. Where is the one for admin functionallity?

Friday 05 February 2010 8:00:51 pm

@magnus: did you take a look at ggsysinfo extension? It might be a step into getting more 'admin' insight into a working system

@matthieu: 'preview' outside of edit would not be 'pre' anymore, but more 'view in front'. I think it is easily doable if it is your need overriding one of the templates that make up the admin interface and addling links to the current node using different siteccesses. But I am not sure it is a real need for all sites... After all navigating the live site is not something an editor should be uncapable to do on its own. What I'd like to see is rather a 'versions' tab integrated in the main node view: with a preview button next to each version (it is already there) it becomes easy to get to preview a draft...

@hrvoje: I see what you mean - but you can click on the icons in the tree to avoid opening the node to which you want to add a child, and use submenu 'create here': 2 clicks

@all: here's how I'd tweak the current design: http://twitpic.com/11ib51 (some fonts are bad and some buttons should read 'create' instead of 'edit'

- more editor oriented (right col)

- button toolbars on top of content areas, statuses/descriptions at bottom

- trashcan icon more aligned to content tree

- versions zone inline in main node view

Generally speaking, agree admin should have 2 "modes": editor and admin. And it should be fast to switch between the two... Maybe not clearly labeled as such, but every screen should fit in only one of the two.

Saturday 06 February 2010 3:56:03 pm

Next iteration:

http://twitpic.com/11oqsf

http://twitpic.com/11oqy7

Changes:

  • properly set the name of the 'craete' button, in case somebdody misunderstands it
  • use language flag instead of full name in language picker: takes up less horizontal space, makes up for less visual clutter (it is not clicked upon in 90% of edits anyway)
  • add an icon to have the nav menu on the left hand slide away 100%. This is independent from it being resizeable via dragging the handle
  • add an icon to hide the main-node-view block, just the same as the childrens block can
  • on the right-hand menu, add settings related to editing/navigating (more on that below)

As for the things that cannot be explained in a picture (ie. behaviors)

  • the currently selected tab in the node block, and the state of hide/unhide for node block and for children block should be remembered while navigating around. I propose 2 modes: 1st: keep the current mode following through user session; 2nd: save this mode per every item (same as in ms windows you can do with every folder). 2nd mode chews up db space and cpu, but here again, it feels natural for people coming from filesystem navigators in the os. PS: the view-mode of children items (icons, list, detailed) should be saved as part of this mode. This is the 1st set of settings on the right hand menu
  • the 2nd set of settings on right hand tells the system where user wants to go after publishing a node: currently this option exists but is hiddden in a completely unrelated place (user page). It needs to be expanded too, as one option that I frequently want is not allowed: go back to viewing node just published. the other 2 options are the existing ones: go back to parent node, and create a new sibling object of same class
  • In the different tabs of the node block, actions should be doable that currently are only accessible from node edit mode but are independent of actual object publishing: hide/unhide (from 'locations'), set obj state (from 'obj states'), set section (from 'details')

More considerations:

  • I tried my best to keep the buttons sets in 1 line, to convey the 'toolbar' feeling. I loathe buttons on 2 lines
  • beside 'move', 'delete' we could have space to fit in there 'hide'/'hide selected', too. Especially if we find an abbreviation for the word 'selected' (maybe write it once only: "Selection: [delete][move][hide]"blunk.gif Emoticon
  • I did not yet put in the buttons for picking different sorting order. I think they should fit in the 1-line-toolbar, maybe making them not-very-wide or putting them in single button + a subpanel that appears via js
  • advanced search should be more readily available (but have an improved, simplified interface, too)
  • last but not least: I do not like too much the right menu starting below breadcrumb and right menu starting below main header. I think dropping down a bit right and menu is better

Thursday 11 February 2010 2:30:30 pm

Only had few minutes to test the admin interface as it is in 4.3.0 alpha. General impressions positive, but the overall design will be improved, especially made less... white, will it not? blunk.gif Emoticon

Wednesday 03 March 2010 1:51:09 pm

Agreed with Piotrek. Design needs to be less white, because at current state it feels unpolished and not very feature packed.

Few suggestions about the new features.

1) Integrate admin2pp extension in the main distribution files.

2) Add drag&drop support for content object tree, not just the list of children objects.

3) Add fine grained control of template block and template compile caches, not just global Clear option.

4) In class list, at the right end of the table, there's a number of objects available for certain class. Make it clickable to list all content objects of certain class.

5) When adding subtrees and nodes to policies, only name is displayed in the list of already added nodes/subtrees. There's no way to find out the actual node/subtree it is referring to if there are tens of thousands objects or objects with the same name. At least add the link and display the subtree path of the nodes/subtrees involved, similar to when adding a role to user group with a limit to subtree.

Wednesday 03 March 2010 2:10:35 pm

>especially made less... white, will it not?

Nope, there hasn't been any good suggestions on how to get it less white, so don't think Christian is planning to do anything with that for 4.3 unless someone has any good ideas..

Current version is: http://twitpic.com/16dets

(One we have considered is something like: http://issues.ez.no/IssueView.php?Id=16255& or just merge the style from this article with what's been done in the current style and provide it as an alternative theme )

PS: eZ Publish 4.3 is currently in deep freeze, so only bugs are fixed at this point and everything else will have to wait until 4.4.0 "Fuji".

Modified on Wednesday 03 March 2010 2:13:01 pm by André R

Thursday 04 March 2010 12:56:44 am

Hi Andre

The current design is quite stark and is major departure from the current look (I've code named it "Polar bear in snowstorm" - PBiS happy.gif Emoticon. Functionally and layout wise I think it's a great step forward, though I am concerned that it's going to cause major issues with a lot of editors.

It would be great to have the option of an old "look" design that can be applied to the new interface to help with this transition.

I think that Thomas' suggestions would help eliminate some of the starkness. You can see his suggested changes here http://issues.ez.no/AttachmentItemContent.php?Id=6953

The major issue I have with the new design is that elements get lost. This is especially apparent on the edit screen where there are numerous information areas in the left hand column. See http://twitpic.com/16ga7r. There is no clear visual separation of the these and this is not helped with the headers being the same size/font/weight as the labels (this is because they both use h4's!) using within the main content. The same applies to attributes - it'a difficult to tell where one starts and another finishes.

The starkness or flatness of the design means that nothing stands out and users have to search for what they are looking for, there is no visual hierarchy that guides users to complete the task.

Taking the edit screen as an example, the center content has to be differiented from the the left hand menu, adding a background to the elements of the main content area helps this. See: http://twitpic.com/16ghn6 for some simple CSS changes that block up the content a bit and make it clearer what the sections are.

I hope that there is still room for cosmetic changes to the interface before 30th March - 6.

Cheers
Bruce

Thursday 04 March 2010 9:02:45 am

Hi,

500 on Bruce messages ! background color to differentiate area seems enough and quite easy to implement 500 on Bruce messages ! background color to differentiate area seems enough and quite easy to implement

Cheers!

Thursday 04 March 2010 9:57:37 am

+1(000)

By the way, A frame aroud the login screen would be nice too happy.gif Emoticon

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from