eZ Community » Forums » Discussions » Redefining eZ Publish User Interface,...
expandshrink

Friday 15 March 2013 1:53:03 am - 11 replies

» Read full blog post

Introduction

Hello all,

Here is the second of the six user stories that we use to craft the next eZ Publish Editorial User Interface! It is about Search and Creating containers such as image galleries. We still have much more to share so stay tuned, and as always, please bring any feedback in the Comment section.

Note: we will soon activate rss on this blog to make it easier to follow (oops...) and each new post here we will also post on twitter using the #eznextui hashtag! Feel free to use it as well.

Friday 15 March 2013 2:38:39 am

Just noticed the uploading interface and I guess it's based on HTML5, really nice happy.gif Emoticon

And the I like the idea of infinite scroll.

Friday 15 March 2013 2:43:53 am

Just a quick question for creating a gallery. In the new admin interface, we can upload images under a gallery before publishing the gallery, but if we "ignore" the gallery without publishing it, what will happen to the images already uploaded?

Friday 15 March 2013 11:46:06 am

Quote from Michael Lee :

Just a quick question for creating a gallery. In the new admin interface, we can upload images under a gallery before publishing the gallery, but if we "ignore" the gallery without publishing it, what will happen to the images already uploaded?

Very good questions, and I would say this is not yet defined. As a user, my best expectation would be: we ignore and make sure the content is not kept anywhere.

Friday 15 March 2013 11:59:06 am

7.1 Is it relevant to display the node priority in a search context (this is perhaps controlled by the cog-icon)?

19.1 Probaly not the best interface if there are many users but I guess the UI for these filters have to be specified further in any case.

22.1 This seems like an unconventional way of displaying actions related to an item list. Have you seen this done elsewhere?

23.1 The box which displays the content types should also provide a search field at the top to filter content types (important for sites with a lot of content types).

Friday 15 March 2013 2:07:37 pm

Quote from Roland Benedetti :
Quote from Michael Lee :

Just a quick question for creating a gallery. In the new admin interface, we can upload images under a gallery before publishing the gallery, but if we "ignore" the gallery without publishing it, what will happen to the images already uploaded?

Very good questions, and I would say this is not yet defined. As a user, my best expectation would be: we ignore and make sure the content is not kept anywhere.

Thanks for your quick response. That makes sense to me.

Saturday 16 March 2013 6:22:53 pm

We could have a problem if there were many users. In this case another subtree would be relevant (with quick filter).

There also might be many content types. This topic has already been discussed once (I mean comfortable viewing). User could see categorized data types (eq. content, media, etc.) and use an additional filter for quick picking (many types using checkboxes).

Saturday 16 March 2013 6:40:51 pm

Quote from Karol Radziuk :

We could have a problem if there were many users. In this case another subtree would be relevant (with quick filter).

There also might be many content types. This topic has already been discussed once (I mean comfortable viewing). User could see categorized data types (eq. content, media, etc.) and use an additional filter for quick picking (many types using checkboxes).

Hi Karol,

Good feedback, thanks a lot,

# about users:

I think you are write but we need here a text field to filter/autocomplete, more than a new tree.

what do you think?

# about content types:

So content types are an extension point of eZ Publish. Something that might be different on each installation. This will clearly remain. We can reduce the number of default content type but certainly not constraint it. Considering this, for the mockup for now, we don't focus on the details of content type used.

What was your exact thought?

Saturday 16 March 2013 6:50:44 pm

Quote from Eirik Alfstad Johansen :

7.1 Is it relevant to display the node priority in a search context (this is perhaps controlled by the cog-icon)?

Indeed, we have a requirement for this view to be configurable, with the cog, and also extensible. By default there is 3 views (data list, editorial list, media grid)!

But we take note! Priority make no sense on the default.

Quote from Eirik Alfstad Johansen :

19.1 Probaly not the best interface if there are many users but I guess the UI for these filters have to be specified further in any case.

Sharp!

I suggest edit field with filtering/autocomplete. We will update.

Quote from Eirik Alfstad Johansen :

22.1 This seems like an unconventional way of displaying actions related to an item list. Have you seen this done elsewhere?

I have seen something similar at Dropbox at somepoint. We have been discussing this one with Rainer. We agree it doesn't work great for now. We need to refine.
I think having the action appearing on rollover (instead of radio button) would be more conventional.

What we want is to have these actions always visible, it would take some real estate space for something which is not important while searching. 

Quote from Eirik Alfstad Johansen :

23.1 The box which displays the content types should also provide a search field at the top to filter content types (important for sites with a lot of content types).

Agreed, sharp.

There are a ton of small things like this that we can only surface having many people using eZP in many context reviewing.

Thanks for your feedback Eirik! Please keep following the thread.

Monday 25 March 2013 10:45:43 pm

Thanks for this user story, I think it is a very important one. In my opinion (and editors tell me too), the current ezp admin UI is not very user friendly when it comes to create complex content classes like galleries, multipage articles or any content objects that rely on related content.

The main problem is that an editor needs to create each parts of a complex content class frist and then combine them by creating the object relation or the parent-child relation. For example, it's a common use case that an article object contains an attribute to store a relation to an image in the media library. So the editor worklow is following:

- create image with all required attributes in the media lib
- navigate to the content tree and create article
- create object relation

It requires a lot of clicks and navigation through the content tree in order to create such an article.

I think it would be better user experience to combine those 3 operations into one single interface - that way the editor is not losing the context.

In your example, the wireframes show a gallery in edit mode which allows to add sub items. Does it only allow to drag&drop existing ezp objects -- or do you plan to allow the editor to create new images?

That interface probably gets crowded if you add 10 images (gallery form plus 10 image forms). Maybe you could implement some kind of a carousel: First item on the carousel is the gallery and additional slides are the related images (subitems). Then you allow the user to navigate between the slides.

Wednesday 27 March 2013 4:52:29 pm

Of course since we work together on the same clients, I agree with Philipp's points. The new interface does indicate that you can create a new object as a sub-item, but it looks just like what the current "smileupload" extension provides. And it looks like the intention is just to re-use the WebDAV / multi-upload framework which is useful but only works for images and to a more limited extent, OpenOffice files with mapped sections.

For a browser interface to create multiple objects at once, we're still relying on the old "create an object within another object" setting quite a bit:

[BackwardCompatibilitySettings]
AdvancedObjectRelationList=enabled

Sometimes we also build our own interfaces for that purpose (by overriding attribute edit templates) and for multi-edit purposes.

To summarize, there is a big need for a more powerful "create an object within another object" experience. Creating an image gallery demos well but only scratches the surface.

Modified on Wednesday 27 March 2013 4:52:51 pm by Peter Keung

Friday 12 April 2013 8:14:49 pm

@Philipp:

So the editor worklow is following:
- create image with all required attributes in the media lib

- navigate to the content tree and create article

- create object relation
It requires a lot of clicks and navigation through the content tree in order to create such an article.
I think it would be better user experience to combine those 3 operations into one single interface - that way the editor is not losing the context.

Indeed, but it is also hard to have something really generic. I wonder if the way to go is not to make wizards here, object relation is not an obvious concept for editors. We'll keep thinking.

 

Does it only allow to drag&drop existing ezp objects -- or do you plan to allow the editor to create new images?

At this stage, we clearly allowed either:

  • drag and drop image file to import.
  • choose one from the media library (or elsewhere).

I don't really see the drag and drop of an existing object, but choose one from the medial library is achieving the same thing.

I totally agree with you on the missing piece here: how to create a content, with is not drap&droppable from a file, without breaking the flow. We will think about that, it could totally be inspire by the "create sub-item" which is available in search listing. We will research happy.gif Emoticon

 

@Peter:

...And it looks like the intention is just to re-use the WebDAV / multi-upload framework which is useful but only works for images and to a more limited extent, OpenOffice files with mapped sections.

Indeed it was the intention. We believe it is a use case very common and we also believe it is hard to make something totally generic. Basically, while solving bigger questions, there is also a lot to do in improving UX on smaller things. The multiupload thingy is great but could deliver MUCH better with the right UX and usability blunk.gif Emoticon but we still try to keep an eye on the big picture of course.

To summarize, there is a big need for a more powerful "create an object within another object" experience. Creating an image gallery demos well but only scratches the surface.

Agreed! We keep this in the target, with the associated question mark "can it be generic, or should itbe specific?"

I will post more about that soon.

Thanks a lot for feedback.

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from