Hey,

I just noticed Media Types was in Structure in Drupal Gardens, this is the wrong section. Media types is something you configure once, and after that touch only on ocassion. Structure is D6 it's sitebuilding, with that in mind not all field configurations neccairly have to be in Structure - especially if used only rarely.

I would suggest moving it to Media in Configuration

Files: 
CommentFileSizeAuthor
#26 Moves the File types menu from Config to Structure3.38 KBtsvenson
PASSED: [[SimpleTest]]: [MySQL] 17 pass(es).
[ View ]
#16 949996.diff3.17 KBarthurf
PASSED: [[SimpleTest]]: [MySQL] 17 pass(es).
[ View ]
#6 media_structure_types.patch1.02 KBJacobSingh
PASSED: [[SimpleTest]]: [MySQL] 17 pass(es).
[ View ]

Comments

JacobSingh’s picture

It's basically a clone of content types which is in structure. Why would it be different?

Bojhan’s picture

Yes, I think the main difference is that it will be used far less frequently. We do not have a navigational pattern for entities and field UI parts - see for example terms and users. Its placed all over the place. I think it makes more sense to place this near other Media configurations, rather than place it far from it (in terms of finding it) and not place in Structure (because of bloating a page, with an infrequently used item)

aaron’s picture

atm, i'm neutral either way. though i admit that i was originally caught off guard by the move, especially considering that from what i recall the #media section was made specifically with the media module in mind, though i'd have to dig up the original issue...

Bojhan’s picture

Yes, I actually discussed with you while we made #550228: Configuration page: Media category

Noyz’s picture

I agree with Bojhan. This totally belongs under configuration

JacobSingh’s picture

Priority:Critical» Normal
Status:Active» Fixed
StatusFileSize
new1.02 KB
PASSED: [[SimpleTest]]: [MySQL] 17 pass(es).
[ View ]

Committed the attached.

Please use critical only for things which stop someone from using the module.
Thanks,
Jacob

Bojhan’s picture

@JacobSingh Not finding your module, stops people from using it :) - I am just using core qualifications which specifies IA bugs as critical.

JacobSingh’s picture

Since this module has been in production for 30k people and there are thousands of postings on the drupalgardens.com forums and not one person has mentioned this in the past 6 months, I don't see this as "unable to use the module because they can't find this settings page."

Anyway, we take UX really seriously, and I would absolutely consider UX bugs critical if an important (80%) feature of the module was difficult to use / discover for a majority (51%) of the people using it. I bet 5% of the user base even goes to this page, and I imagine most of them can discover it, so I while I agree that moving it makes sense, I couldn't consider it critical.

Maybe other media module maintainers feel differently, but that's my take.

Where does it say that *all* IA bugs are critical in http://drupal.org/node/45111?

Critical
Critical bugs either render a system unusable (not being able to create content or upgrade between versions, blocks not displaying, and the like), or expose security vulnerabilities. These bugs are to be fixed immediately.

In Drupal 7 this also applies to test failures: we have a policy of a 100% pass rate for tests, so failing tests block all other development.

Major versions of Drupal core (like 6.0 or 7.0) won’t be released until all critical bugs are fixed. For point releases (like 6.1 or 6.2), critical bugs won't hold back a core release if a security update is needed.

In contributed projects, it is up to each maintainer how they handle the critical status.

Bojhan’s picture

Probably best not to discuss this over in a already fixed issue. I do wish to explain though there are several reasons why I would mark this critical :

1) Finding functionality is critical (that there has been no reported issues about this, to me says little. For example, the most critical findings of usability tests on D7 showed inability to find "create content" as a big issue - though this is hardly ever reported in issues/forum posts).
2) It breaks with convention where you would go to find "Media" configuration (keeping concepts like this in tact is important when more contrib modules start adding their functionality)

I am sure people will find this, after all its in Structure which only has some 7-12 links most of the time - but it might take them longer than needed, this we way prevent that.

I only marked this critical because of 1) and 2) and because of the value we put to it in Drupal 7. Obviously any contrib maintainer can take his own judge on that. The Priority page sadly is incorrect, it says little to nothing about how to handle UX issues (for example, by its definition of critical nothing hard to use would be considered critical as long as you can use it - in reality we have escalated quite a large number to critical)

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

marcvangend’s picture

Status:Closed (fixed)» Active

Sorry for arriving here this late (I was redirected here after I opened #1165400: Move menu items from configuration to structure myself), but I strongly disagree with the decision made here.

Last week I have been playing with Media module, finding out what it does and how to use it. Having experience with D5 and D6, the knowledge that there are many similarities between file entities and nodes helped me to understand what I needed to do. However, new users will also quickly find out that there are similarities between nodes and media. Looking at the content section, Media follows the navigation structure of the Node module (/admin/content/node, /admin/content/media). That's why I also expected Media to follow the Node module in other parts of the administration menu.

Basically, the argument to move Media types to configuration is that it's used less often than Node types. I haven't seen proof for this statement. After a site is published, I don't visit the node type configuration pages often either. I don't see why I the Media type pages would be any different in that respect.

More importantly, the IA is not structured around the frequency of use to begin with. The IA is structured around meaningful topics such as 'content', 'structure' and 'people'; they are not called 'daily tasks' and 'initial setup'. The fact that some sections will be visited more often is a logical result of structuring by topic, but it should not be a goal in itself.

drzraf’s picture

I would add that
"/admin/config/media/file-types/manage//fields"
page should show the name of the "file type" it deals with.

diqidoq’s picture

hm .... I have to agree with marcvangend. I remember the 2 days on IRC where I made a fool of myself wondering where these media files will be set up now, but it was already there. I think the most counting argument here is the "manage fields" and "display fields" feature which is 100% expected near to the pendants for content types. Even if it doesn't work yet fully, the admin structure shows where media and file_entity plans to go (hopefully) and this is definitely site structure and for the D6 users site building in mind, but not configuration settings, what is more about general settings of the site and some configurable modules.

And somebody who is using all the file types already provided will use this manage fields part for files very often.

gollyg’s picture

Just weighing in on this. I agree with #11.

A pattern has been established in core that node entity bundles are configured in structure. Configuring a file entity couldn't be more analogous as an operation. By storing it under structure you are working with the user's mental model of how entities are configured.

I don't feel that the rationale of 'it is not used much' is really the guiding principle for the IA - if it was our main menus would be structured along the lines of 'most popular' etc.

arthurf’s picture

Project:Media» File entity (fieldable files)
Version:7.x-1.x-dev» 7.x-2.x-dev
Category:bug» task

I think this actually belongs to file entity

arthurf’s picture

StatusFileSize
new3.17 KB
PASSED: [[SimpleTest]]: [MySQL] 17 pass(es).
[ View ]

This patch just moves the menu items around.

arthurf’s picture

Status:Active» Needs review
marcvangend’s picture

Thanks Arthur. The patch looks good, I'll try to test it later this week.

Noyz’s picture

I don't have a strong opinion here given that both arguments are valid:

  1. Why muddy a menu items that houses everyday features like Basic Pages, Menus, Taxonomy and Views with 'preference-like' features that configure your site?
  2. Conversely, why separate 'like' features that provide context in order to prevent muddying a menu?

Honestly, I think the catalyst of the problem is the IA itself. Config vs Structure vs Content continuously confuses both end users and developers. End users don't understand why some things are content where as others are structure, and developers aren't sure where users should interact with their module. Until this problem is solved, no solution is going to be ideal.

That said, I side on a solution that best maps to a long term strategy. In my mind, that long term strategy is one where 'Structure' is a thing of the past, and 'preference-like' features are grouped together. For me, keeping the location under config is a better long term plan. I hope and pray "structure' goes away in D8, and as such, it seems foolish to place it there. Doing so means in D8, people will again have to ask this question "where did media types go?"

Dave Reid’s picture

I'm not so sure on this either. To configure user fields and how those fields are displayed, it's located under config, not structure. That said, it does seem to make more logical sense to put it where everything else puts their bundle admin screens.

Noyz’s picture

Another possibility...

Move both Content types and Media types out of Structure and into Config. Under 'Content', create a "add a new content type" link. https://skitch.com/jeff.noyes/gsj4t/add-content-jeffer

Rationale:
1. We know from many usability studies that new users have no idea that you can extend Drupal's content types because adding new ones is not in the proximity of existing ones. Although we haven't done so yet, I have a high confidence level that adding such a link will bridge a major gap for new users.
2. Placing Content types and Media types both under config solves the relationship issue outlined in #11
3. Placing Content types and Media types both under config solves the issue outlined in #19 where Structure is muddied by everyday items (pages, views, taxonomy) with non-everyday-preference-like features (content types, media types).

Dave Reid’s picture

Sorry, but this is not viable nor acceptable for Media or File entity to alter around the Content types menu...

Dave Reid’s picture

Title:Media Types is in the wrong section» Move admin/config/media/file-types to admin/structure/file-types
Assigned:Unassigned» Dave Reid

Issue #1431688: Fields translation path exceeds the maximum menu parts has identified that we cannot continue to let this path live under admin/config and that moving to admin/structure would be an improvement with enabling translations of file entity fields.

Dave Reid’s picture

So in other words, until the menu router system is more flexible, neither file types nor any type of structure item can or should live under admin/config.

tsvenson’s picture

Was actually planning to give moving file-types a go after I got the MSS feature done. Seems like an easy task for me to take on. Assign it to me if you think I'm up for it.

And yes, I do agree with those that says it belongs in Stucture and not Config.

tsvenson’s picture

StatusFileSize
new3.38 KB
PASSED: [[SimpleTest]]: [MySQL] 17 pass(es).
[ View ]

Patch in #16 isn't working. The tabs doesn't render properly. Here is a new one that fixes that.

tsvenson’s picture

Any progress on this one?

The patch works, but the change requires a few cache cleaning/reloads for Drupal to stop throwing errors. So, the sooner we can get it committed the better.

Dave Reid’s picture

It would be really good to maybe get Bojhan's opinion on this. We have lots of reasons why this 'revertion' is beneficial:

  • People are used to configuring their entity's display and fields under 'Structure'. We've had more people get confused about where to go configure their file type displays now that it was under admin/config/media/file-types.
  • The file_entity module now actually has file/%file pages that are visible to end-users unlike before.
  • If we want to enable translation of file entities, we are unable to do so under admin/config/media/file-types because we will hit the 9 argument depth limit for menu router items. For example, admin/config/media/file-types/manage/image/fields/field_image_title/translate/fr is 10 segments.
Bojhan’s picture

I wasn't aware this was already in. In general the comments of marcvangend in #11 are still the valid reason for this living in config. The concerns express by jeff noyes are valid, but also out of scope for a contrib to solve.

In terms of the downsides you express;

1) We don't really have a pattern for entity configuration, as you might notice - the random placement of comment, taxonomy and user field configuration. What we have done instead is try to place everything close to each other, the same applies here. There will be confusion however, because you move something. We learned through D7UX, that moving items is not met with much love :)

2) I don't really know what this means, for where you place it.

3) This is a very stupid core limitation. Feel free to patch it, I have done so already from 8 to 9.

tsvenson’s picture

@Bojhan: The patch isn't in. Adding/Managing fileds/displays for media has always been in Configurations.

As I see it:
Content = For content editors
Structure = For site builders
Configuration = Site administrators

For me, adding and managing fields and displays for the media types is a site builder task similar to working on the structure/display of content types and taxonomies. So, the logical place for doing the same for media types is in the Structure section, which is where the patch in #26 is moving it to.

Dave Reid’s picture

Status:Needs review» Fixed

Sure, we can fix the Drupal 8 menu router to have more than 9 path segments (and WSCCI likely fixes that for us), but for D7 we're locked in at 9, so I have to pull this trigger now otherwise we're blocking support for File translation. We can re-review this IA when we attempt to merge the file_entity module into Drupal 8.

The patch in #26 has been committed to 7.x-2.x: http://drupalcode.org/project/file_entity.git/commit/86ba3ff. Question is now do we back-port this to Media 7.x-1.x's file_entity? I'm inclined to say no because it's not a bug, but I'm also inclined to say we should for consistency with 2.x.

tsvenson’s picture

If its not a problem/bug for 1.x, then I see no reason to back-port. Also, there are so many other things that changes in 2.x so consistency is nothing to worry about :)

Release notes will need info about that clearing cache a few times and reloading pages might be needed. Was quite tricky to get it working without errors.

Dave Reid’s picture

All you need to do is run update.php, even if there's no updates to run. That should move the menus without error.

tsvenson’s picture

Ahh, that's great. Good thing we got this patch in before rolling the "DrupalCon" unstable release then :)

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.