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

Wednesday 02 December 2009 12:26:25 pm - 50 replies

» Read full blog post

Introduction

eZ Publish 4.3 will take a big step towards refreshing the administration interface.
A requirement document and a html concept prototype were recently uploaded to our SVN repository, detailing the back-office-design-related features to be implemented in 4.3 and beyond.
This document already took into account the results of this survey : https://www.surveymonkey.com/s.aspx?sm=XdceP232zMtVeQApNduLrg_3d_3d.
The actual implementation of the proof of concept starting soon, it is about time to tell us what you think.

Thursday 03 December 2009 2:53:34 pm

@Magnus: #node information: making a pr user drag and drop widget interface is not something for this iteration, and I'll leave it to the UI guy to figgure out if that is really needed or if it makes sense.

#context menu: Hover is something that happens when you hold the mouse over something (still or moving, it doesn't matter), so no click and as a new users she'll see it clearly if she hover over any of the rows in the sub item list and immediately understand that there is something she can do here. And if she then moves the mouse to the menu icon she will get title info and a menu of actions will slide out.

@Tony: To large to put it in now, but I'll point the UI guy to this when a more big WCAG / ATAG / UI push comes in the next releases, for now evolution and esthetic's.
As for live chat: I do not agree, why should we spend time on something you can do much better with so many other communication platforms today? And there is really nothing stopping the community from making something like this, it is completely stand alone and would not need a single hook in the kernel or admin interface to be able to live as an extension. A couple of partners even have 3. party integration solutions for this that they might share if asked(I do not remember who, ask bm if your interested and he will probably know).

Also: "We have many clients who use a folder as a bucket", you have always had the option to "search here" in the header, so with ezfind and medium searching skills you'll be well covered. But I guess people tend to forget it so there should be something in-line in the subtree box as well?

@paul: Create here: will look into that, Image: That is something for a online image edit/crop tool, so separate project and you'll probably hear more about it soon.

Modified on Thursday 03 December 2009 3:14:14 pm by André R

Thursday 03 December 2009 3:29:38 pm

@Paul: On "create here" what if it by default uses classes pr class group that for the content / media / user / setup tab? (in addition to create rights of course) Right now it works like that for user tab, but on every other tab it just exudes user and setup classes.

Thursday 03 December 2009 5:19:02 pm

Hi André,

No. Referring to the content ajax menu .. you can limit displaying subnodes.

Thursday 03 December 2009 6:36:22 pm

@Magnus: #node information: making a pr user drag and drop widget interface is not something for this iteration, and I'll leave it to the UI guy to figgure out if that is really needed or if it makes sense.

#context menu: Hover is something that happens when you hold the mouse over something (still or moving, it doesn't matter), so no click and as a new users she'll see it clearly if she hover over any of the rows in the sub item list and immediately understand that there is something she can do here. And if she then moves the mouse to the menu icon she will get title info and a menu of actions will slide out.

#context menu: I think I get what you mean. Zero clicks to obtain hints on what actions that are available to the user, not actually performing them. (I atleast need to click the row on dropbox to open the menu.) That kind of indication would indeed be useful for beginners. My concern was the amount of clicks needed to perform an action and with dropbox style it is the same so that concept would probably work out fine.

I like the idea of comparing the tree menu with, for example, the one in Eclipse where a single click gives you a bunch of useful options. Just like it is today and removing that functionality doesn't appeal to me all.

As for the other changes I'm totaly for them.

What about collapsable object attributes in edit mode? Like blocks in eZ Flow edit mode.

Thursday 03 December 2009 9:10:15 pm

Hi Andre,

Thanks for the feedback, I think that you are right about the third party support for messaging. Will the new admin interface allow extensions like this and still be covered by the eZ Premium support contract?

"@Tony: To large to put it in now, but I'll point the UI guy to this when a more big WCAG / ATAG / UI push comes in the next releases, for now evolution and esthetic's."

Which point is too large for now? and what does WCAG & ATAG mean please. I was under the impression that the new admin interface was a rewrite so there should be some freedom to resolve some of the issues hopefully even if it is an evolution.

Fingers crossed

Tony

Friday 04 December 2009 8:10:19 am

@Tony: "To long": to many points for me to comment on for now, but ignore that and lets get down to it then..

Admin Interface

#1: Allow drag and drop of pages and subpages etc
Already in, there is also a user story about dragging tings around in content structure menu but it's on hold until we properly fix the possible timeout issues it can cause currently.

#2: Change the language of the admin interface for editors. Do not use technical terms.
Will have to do multi variant testing with fresh users to get that right, a thing for new UI guy. But suggestions are welcome of course.

#3: clean up permission admin and viewing of content to make it easy to change/update..
Not sure I'm following you here, what did you mean?

#4: Create a clipboard area/folder (per user and per group) where folks can work on drafts and share with others
Half of it is covered, by providing a dashboard box for your last stored drafts. So more easily being able to share before it is published would need to be looked into separately, but most of the bits are already in place (version view) so shouldn't be to hard. (Yes, I left out the folder part you mentioned as it will need far more changes to how things work now).

Media Library

#1: Have pr site media library on multi site same db setups that have just 1 admin siteaccess
Yes, long standing issue for multi site installs. The "solution" I can come up with is something I did for the first ez site I created for my then student union. That is to setup sub folders in image/video/files and set up general roles that where assigned with limitation to these folders depending on what user group you where in, and then tweak content.ini settings to automatically pick the sub folder you have access to. But ideas are welcome of course happy.gif Emoticon

Articles

#1: Most edits just require a change to a title and to body copy so a simple edit view of a page is needed
I think what your looking for is inline editing, as in double click or have a interface to let you edit text without leaving the page. This has been left out as we still haven't agreed on how this should be done in relation to versions, the most proper way is probably to do versions (and not change existing version directly) so we will need a interface where you click "commit" or publish when you are done with your changes, as opposed to publishing a new version for every attribute you change.

#2: Fix the whole Title issue, I have seen many implementations with the Title and Nav title and event, Breadcrumb title
I assume what your saying is that some classes have slightly different logic for title vs short title (menu's & url's) vs url titles (url's) and so on. And they also use different names for attributes that has the same purpose ( into/description & title/name ).
So basically more of a consistency cleanup of our out of the box classes in ezwebin and ezflow. Correct?

#3: Add Editor notes to the field so folks can link to a page we can add content to to help the
This is what we refer to as Class and Class Attribute Description and is a long standing enchantment request for eZ Publish.
There is a user story on this, but it is not on current 4.3 road map, these are things you'll have to push Roland for (devs already do).

#5: Add system information in another tab so folk can see where in a workflow a page is.
Not sure what your asking for as systems information (apache/php/ezp/ezc version information) is not really related to workflows.

#6: Ensure that even if an image is uploaded in a datatype and not linked to it can still be referenced/ used in the document
Also not really within the scope of this discussion.

Our current approach is evolutionary, so lets keep on topic please.

Modified on Friday 04 December 2009 3:56:23 pm by André R

Friday 04 December 2009 8:32:38 am

@Magnus: Good, and thanks for the reference to eclipse. But I still think menu in content structure menu should be more visible someway maybe like the proposition for sub items. Right click/ context sensitive menus aren't normal on the web, so most users that are used to the web don't expect them to work like applications and have those. I tried to Google for a reference for this, but couldn't find any design patterns for context sensitive menus on the web.

Friday 04 December 2009 11:28:21 am

Hi Andre

From the tone of the reply, I get the feeling I have offended in some way. If this is the case I apologise.

"@Tony: "To long": to many points for me to comment on for now, but ignore that and lets get down to it then.."

"(For perspective: this post took about an hour to write, time I should have spent on implementing )"

My only wish is to ensure the wishes of the editors who I train and myself an eZ editor and analyst get the best experience. Part of that is ensuring the thinking and basics are covered. It sounds like those are set for this release.

It also appears I mistake the scope of the project for one of a revamp rather than an evolution, again I apologise for this.

Please let me know where I can help best.

Tony

Friday 04 December 2009 12:05:45 pm

@mark: issue about drag'n'drop support is here: http://issues.ez.no/015887 - I think using it consistently everywhere is as important as having it available on most used lists (this is a general tip for all new features: they have to be used everywhere they apply)

@felix: more interaction of user-rights with the tabs and available menu items is underway. Iirc AR has already committed it for the items in the left menu on the setup tab

@magnus: i personally think tabs are better. Right now we have too much info on screen, which is bad for editors and only good for coders/admins, and we do a lot of vertical scrolling. To scroll I can use navigation keys, but most users use scrollbar, which involves moving mouse to right edge of screen - which is not much worse than clicking on a tab anyway...

@tony: a per-user pref stating his preferred lang for admin interface: +10

@paul: not sure I grok your request for limiting "create here". right now it is doable and totally integrated with the permissions system. Only admins should ever see the full list of available classes

@magnus: +1 for collapsible attributes in edit mode. Here again, it should be applied consistently, eg. also in class edit mode...

Other stuff:

- adding a "description" field to every attribute is such an old feat. request it's not even worth discussing. But it involves changing data model, not only UI...

- I'd deprecate completely the ini setting for 'items that appear as folders in the left menu' and use the 'is-container' attribute of classes to decide that. Not strictly part of ui code, but I think it's a useless piece of configurability that has at best no positive impact and at worst negative impact on UI...

Friday 04 December 2009 1:05:09 pm

@Andre: Image: The simplest way would be to have two lists of image aliases in image.ini: 'show in content area' and 'don't... '. Obviously you could get a lot cleverer than that - have user editable aliases, aliases which do or don't allow particular CSS classes (to allow borderless images when required, for instance) - but, as you say, that's a whole sub-project.

I think it's an interesting UI problem though: What do users, and their administrators, actually require from a CMS image processing system? How can we give them the freedom they need without allowing them to make a dog's breakfast of the site?

Your second comment regarding 'create here' - I'm still trying to work out what you mean.



Modified on Friday 04 December 2009 1:06:37 pm by paul bolger

Friday 04 December 2009 3:09:13 pm

Hi, added a sketch of the suggestion with a horizontal divided layout.

http://skitch.com/gerhardsletten/nkfcm/ez-interface-01

Friday 04 December 2009 4:14:09 pm

@Tony: I got a bit out of hand there, just too much I'd like to do and too little time.
Basically we can discuss the things you had under Admin Interface and I commented on, many of those are doable for 4.3 and especially #4 where good.

@Gerhard: Cool, I get the picture now, can't promise anything, but with a intuitive icon for toggling this could make sense.

@Gaetano: Good idea about showing classes that are containers automatically, won't work for articles though.

@Paul: Basically when your in content tab, you'll only see classes that are placed in content class group. Only pit fall right now is that you'll lose visual access to create folders in media tab until you manually add folder to media class group in addition to content class group.

Modified on Friday 04 December 2009 4:16:59 pm by André R

Friday 04 December 2009 5:52:26 pm

It's great to see you are working on a new admin interface - and are including us in the process. As a long time user I've got many ideas what should be done differently. Most of them has been asked and answered here, but I'll add some that are important to me.

Preview node content
Like in the new OE, you can grab the bottom right corner and resize the area. The preview should have this. The default today is not high enough. Additionaly, there should be a "Open this node in public site link".

Help
I read somewhere you are focusing on the editors, and I agree. Add a help system. Google does this very well. Using small clickable help-icons, that, when clicked, displays a help "bubble" with a very short and concise description. I work in an information center with 6 colleagues. All of them more into the "writing stuff" part then the technical side. They always ask repetitive questions that could easily be answered by a help system like this.

Role based layout
I would also encourage you, like many here has pointed out, to use the role system to show/hide information in the interface. For example, you should only be able to see tabs that your role has access to.

Content structure
Today only a few classes are shown by default. In my view, all classes should be viewed by default, but limit the number of nodes that are fetched and add a "load more/view more" link to the end of that child list. Or maybe create a setting where you add classes that you now you have a lot of and give this functionality to it.

I read that you don't prioritize it for this version, but I'll add it anyway. Please add drag and drop functionality.

Header
The header (logo on the left, search on the right) takes to much space. Merge tabs and header into one, but make it a bit higher then the tabs are today. Start with a small logo if you need one - maybe just the squares. My editors do not care what the name of the system is, I as administrator already now, then the tabs. On the right side you put search, logged in user as a link to the user view and a logout link. Put version number in footer.

Exit edit mode
When editing, the editors sometimes use the browsers back button to exit edit mode (instead of publish, discard or store and exit). This is just the habit of users on the web. Use javascript to check for user navigation and fire a confirm dialog. Or create a cookie/session variable every time you start editing that is removed when editing is properly exited. If this session is available in normal mode, display a error message somewhere on the page.

Sunday 06 December 2009 11:48:18 am

Help

Help, tool tips or whatever - and editable by the uber-admin - would be great. Training the editors is a major issue in my experience. I really don't want to have to muck about overriding admin templates, an upgrade nightmare, but need to be able to pass contextual info on to editors.

 

Role based layout
Yep, show them what they need and nothing more. Colour coding at higher levels to show who can see what might be nice too.

 

Content structure

Yes: show everything unless it's specifically not shown.

Header

Hate to say it but, yes, screen real estate is at a premium. I don't mind showing a bit of ez branding, but the less space occupied the better.

Tuesday 08 December 2009 1:51:27 pm

It might be interesting to turn the main tabs into a real menu with drop down. I am thinking for example on making entries from the left menu in the setup tab directly available.

Thursday 10 December 2009 9:10:28 pm

You need to take more radical redesign approach.

 

Our customer have lot of problems with ez administration interface. They cry for their old web sites with Joomla or past custom-made CMS-es. Yes, it is so bad with ez admin happy.gif Emoticon

 

Most of time in administration is spent on one thing - editing and managing content. Not translating into another language or moving locations, not viewing related objects.... Yes I know front-end editing is little easier but you can not do everything from there, pages are heavier (longer loading times) and not every site is the same structure so unversal back-admin interface is learn once, use many-times).

 

You should spend most of the time on making Editing/managin content logical and easy

  • make way to group class attributes into tabs (for example: content, media, meta attributes, extras). (for editing content, not for defining classes). When talking clases - it will be more useful to have external XML definition of classes and simple way of reimporting of XML when new attributes are added of classes are define, instead of builing ajax GUI inside administration
  • make picture library as separated panel visible as sidebar (searchable and draggable). Something like Apple Media Library Browser in iMovie and other iLife apps. We have 50.000 pictures objects in media library, most of the times picutres are reused...this whould help a lot
  • detailed help for every attribute (not tooltip, more like help baloon) - remainder for users for optimal picture dimensions etc (who can remember all this)
  • preview of unpublished content - with one click, new window, without ez GUI around
  • search everywhere with relevancy and advanced filtering options (category,kind, creator, time filters etc). I should be able in 10 seconds set search like this "find objects modified in last 7 days within node "News"blunk.gif Emoticon or "all commens today from whole site"
  • live preivew from list-view and search results view (like pictures have prevew in Insert Object when browsing Media library). This will help finding rude forum posts and comment and generaly help...

I will try to make over the weekend some wireframes with my ideas...

To conclude - depending what is the future of Administration interface. If this is developers only tool for seting up classes and privilegies - then no need for radical changes. If Administration is to stay as interface for editing and managing content - then it needs radical redesign and new functionality...

Saturday 12 December 2009 12:50:13 pm

@Gerard: I like the idea of "edit" vs. "manage" views, I think you should be more radical. In "edit" mode remove content navigation and buttons used for moving stuff around / managing versions / translations / nodes, maybe add live preview. In "manage" mode do the rest.

@Andre: what is so special about articles vs. content-tree-menu?

@Borge: good idea of using js to avoid 'back' button click when editing a new draft - recording the edited fields would be a boon, as we could discard draft if no edits where done instead of saving it...

@Hrvoje: grouping of attributes either in separate tabs or just adding gray boxes with a title: +10. Of course the next request is to allow different roles to be able to only edit attributes in group x and not y, etc... blunk.gif Emoticon

Monday 14 December 2009 8:49:24 am

@Gaetano: It's a container because of comments, but it is something a site can have dozens of in a folder which would make the tree menu more or less unusable. But, we are going in the direction of move things like comments out of the content structure, so your suggestion could make a lot of sense.

But where did @Gerhard talk about "edit" / "managed" views?

@Patrick: Thanks, depends a bit on the suggestion to not show all tabs by default though (have a 'more' dropdown for the > 5 tabs). Still doable of course, but a bit more complex and visually harder to grasp.

@Bjørge: Context sensitive help is already in the document(if your talking about class attribute help text, see comment to @Hrvoje), the header stuff you are talking about is also taken care of in document and previewed in concept screen shoot. Role based layout was implemented for tabs and left menu last week, see follow up blog post blunk.gif Emoticon And thanks for the back button protection stuff, won't be easy to track changes to determine store / not-store across all data types, but should look into it at least. Content structure menu, I personally don't think that will make sense for anything but super small pages. And think we should maybe look into adding alphabetical filtering on sub items instead first. It will make more sense to implement @Gaetano's suggestion to make it show containers by default in my mind, and more conceptually right considering it is mimicking folder tree views from most files system browsing programs.

@Hrvoje: A radical approach is not possible as we want to archive something for 4.3, instead we'll do a iterative approach so we'll improve it more for each version.
As for the content model improvement(grouping and help text for class attributes), this is already suggested in a specific thread for it, take a look there and see if we missed something. Just make sure your people push my people (sales/marketing/management) and it will hopefully happen someday blunk.gif Emoticon
BTW: For 4.3 we are considering improving the media library, so not as radical as your suggestion but any specific feedback on this is highly welcome.

@All: Please place all new topics / suggestion in follow up blog post:
http://share.ez.no/blogs/ez/admin...ake-2-tell-us-more-of-what-you-think

Modified on Monday 14 December 2009 9:06:22 am by André R

Monday 14 December 2009 10:09:55 am

@ar view( gg.manage ) == view( gs.organize ).take_it_further

Modified on Monday 14 December 2009 10:10:51 am by Gaetano Giunta

Monday 14 December 2009 4:40:18 pm

@Gaetano: What? I think your hinting about extending some concepts in some views in something called gg and gs, but doesn't really point me to where @Gerhard talked about it so I can understand what you think he proposed.. :P

Modified on Tuesday 15 December 2009 12:57:03 pm by André R

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from