Drupal relies on users to A) Know to pay attention to the URL when creating content B) recall a URL by memory.
Three years ago when I was introduced to Drupal, I pointed out that forcing people to know the path was a serious usability issue given that A) everyone needs to create menus B) menus are one of the first thing a person will do in Drupal. Recently, we ran a usability test at Acquia, and this issue surfaced again as a major problem.
Here are some designs that would fix this issue:
Comment | File | Size | Author |
---|---|---|---|
#13 | 01_Add link to menu.png | 433.22 KB | Noyz |
#13 | 02_browse for content via modal.png | 521.09 KB | Noyz |
#10 | 01_Add link.png | 437.19 KB | Noyz |
#10 | 02_Modal conent browse.png | 520.36 KB | Noyz |
#12 | 01_Add link.png | 433.22 KB | Noyz |
Comments
Comment #1
effulgentsia CreditAttribution: effulgentsia commentedsubscribe
Comment #2
David_Rothstein CreditAttribution: David_Rothstein commentedI'd suggest labeling the fieldset something along the lines of "Placement of link within the menu" (but probably shorter).
And also, leave the fieldset open, not collapsed - this isn't a concept people are likely to understand easily enough to know if they want to open a collapsed fieldset to configure it or not.
Comment #3
effulgentsia CreditAttribution: effulgentsia commentedMostly, I think this is great. Since this is filed as a D8 issue (as it should be), let me blue sky a little:
I'm not saying we need all of that solved before proceeding with this issue. This issue is awesome on its own. Just an idea for something I'd love to see happen some time during D8 development.
Comment #4
Jeff Burnz CreditAttribution: Jeff Burnz commentedEarly days and this looks great - would the intention be to use a modal even when overlay is disabled? How would this degrade without overlay?
Comment #5
Noyz CreditAttribution: Noyz commentedAll awesome information. Let me chew on what it means for this UI.
Comment #6
Noyz CreditAttribution: Noyz commentedComment #7
Noyz CreditAttribution: Noyz commented@effulgentsia
I've chewed on this, and have a reply.
That UI is far too complex. I think the one we have here is better. I think the node reference UI could be redesigned a bit to roll up to this solution.
Agree. We're seeing that same issue in testing. I think we can isolate that issue from this conversation though. Said differently, I think a solution to that issue, can work with this solution.
My hope is that it is, or at least starts too. You'll notice that it's the exact same UI (plus or minus a few fields) for adding a field in Views. Internally to Acquia, we have stories to migrate the existing media UI to look/act more like the Views modal. That said, I think w're on the same page, however since you called it out, I'd like to know if you see particular areas where the UI deviates/falls down from this goal.
Comment #8
cbrookins CreditAttribution: cbrookins commentedIn the browse dialog, I may not be able to recognize my content from just the title.
So I'd want a way to click on a piece of content and open the full page in a new window if I want to see it 1st.
Also I'd like to see a chunk (1 line) of the body in the grid. I think that is more important than the date. So I'd vote for 2 rows like the views listing and show:
Title Author, Updated, Operations
Body text (1st line)...
We could add a "View" link under operations to view it in a new window.
Comment #9
effulgentsia CreditAttribution: effulgentsia commented@Noyz: thanks for #7. Yeah, getting a fully unified UI that covers all use-cases will take time, so doing it in manageable steps makes sense, and keeping this issue to just dealing with selecting an existing node to build a menu link to, is a good scope. As long as we're aware of the larger goals, I think that's good enough for now.
I think my biggest concern with the design now is the auto-update and lazy load. Some sites can have 10K, 100K, or 1M+ nodes. Most of Drupal uses a pager for listings pages. The auto-update text filter is great in the Views UI for adding a field/filter/sort, but that's because it's very unlikely for any of those listings to be >1000. How do you envision this working for very large listings?
Comment #10
Noyz CreditAttribution: Noyz commentedupdated designs. Lazy load is still in, but auto update is out. Also a few tweaks to nomenclature.
These designs are outdated. There's a caching issue going on here.
Comment #11
Noyz CreditAttribution: Noyz commentedHrm, seems to be a caching issue. those last files are incorrect.
Comment #12
Noyz CreditAttribution: Noyz commentedTrying again. Damn, same caching issue.
Comment #13
Noyz CreditAttribution: Noyz commentedTrying again with renamed files
Comment #14
Bojhan CreditAttribution: Bojhan commentedsubscribe
Comment #15
Everett Zufelt CreditAttribution: Everett Zufelt commentedWould love for screen-shots to have some form of description so that we can all play.
Comment #16
Bojhan CreditAttribution: Bojhan commentedI have re-prioritized this to be critical, because any user that does not understand the concept of path will struggle with this issue and in addition to that the overlay adds something to the URL making it really hard for those who do understand the concept, to know which part of the path they need.
This issue was identified in both Baltimore 2009 and now again in Minesota 2011. It was identified as "Path fields as presented lead users to be unsure what to add.".
We had similar solutions proposed as in this issue.
Comment #17
David_Rothstein CreditAttribution: David_Rothstein commentedComment #18
Noyz CreditAttribution: Noyz commentedall screenshots are numbered with callouts to the right.
Comment #19
webchickEverett: Here's a textual description of the latest screenshots, so you can play, too. :)
#1: Add menu link screen (admin/structure/menu/manage/main-menu/add)
"The path for this menu link. This can be an internal Drupal path such as node/add or an external URL such as http://drupal.org. Enter to link to the front page."
The proposed screenshot changes it to:
"Find or enter the path to your content, e.g. node/1234 or http://drupal.org. For the sites [sic] front page, enter <front>"
#2: The "browse" box you would get when you hit the "Find content..." button
This screen, which appears in a D7 Views-style overlay, essentially looks like admin/content; a large table of available content showing columns of Title, Author, Updated, and Operations (in this case, "select" rather than "edit/delete"). There are also filters on the top, though slightly different than those currently at admin/content (presumably, we'd want to make them the same):
- Title or body: [textfield for keyword searching]
- Author
- Status
- Content type
The idea then would be that for users who like to create content and then build out their site structure, they could come to Structure >> Menus and start making their outline, and instead of having to go to a completely different screen to figure out what node/XXX they should put there, they could instead easily browse for existing content.
Hope that helps! (And also, subscribe ;))
Comment #20
Everett Zufelt CreditAttribution: Everett Zufelt commentedFrom an accessibility perspective I'm not comfortable with any design that will rely on a dialog or overlay to present content to users.
If this design can leverage the D7 Overlay in some way, so that if a user or site has Overlay disabled then there will be a graceful degradation that would be great.
Comment #21
webchickI should point out though, that this is only part of the battle.
A decent number of UMN participants, when presented with a site mockup, wanted to start with structure *first* (building out About, Events, etc.) *before* creating any content. This is how I used to build sites before Drupal, too.
So in addition to finding existing content, I think we also need the ability to add content here, and have the checkbox pre-populated. (Obviously as part of a separate issue, but not sure if it makes sense to factor such functionality into the mocks here.)
Comment #22
effulgentsia CreditAttribution: effulgentsia commentedRe #21, see #3, #7, and #9.
Comment #23
Noyz CreditAttribution: Noyz commented#21 adding content is a nice to have that we should figure out how to grow into. I see two major issues
1. We're asking users to remember paths in order to connect a menu to a node. Most users will not even look at the path let alone remember it
2. Users want to add content to a menu. For example, we regularly see people that want to add pages via the menu.
Number 1 is an easy fix. I consider this critical. So much so that I wish we could patch D7. The rationale is that when exploring a site building tool, one of the very first tasks people do is to try to add pages, i.e., work with menus. As such, one of the very first experiences with Drupal is a problematic one which can -most likely will- set the tone for the rest of the experience.
Number 2 is a harder fix. I also would love to see this fixed soon, but its a harder problem. It should be solved, but we can solve item 1 without item 2 and see a vast improvement. Additionally, the fix to item 1 should gracefully scale into a solution for item 2.
Comment #24
effulgentsia CreditAttribution: effulgentsia commented#23:
#20:
This second statement is a major (though probably not the only) reason we won't be able to backport this to D7 core. But, if/when someone has development time to spend on this, it can be done as a D7 contrib module, which would allow for some iteration between D8UX thinking and real world feedback from D7 users, as well as working through some of the thorny issues like accessibility.
Within D7, I don't think we yet have a clear standard for dialogs. We have the dialogs presented in the D7 Views UI, which are based on jQuery UI dialogs. In #1139514: Overhaul the media browser code to not use an iframe, and be more understandable, maintainable, and extendable, we're currently working on porting Media's media browser to a similar style of dialog. However, there are definitely accessibility issues that still need to be worked through with these, and if we want this to become a UX pattern in D8 core, then we MUST solve the accessibility issues.
I think there's a significant UX difference between the Overlay module overlay, and the kinds of modal dialogs needed in Views UI, Media browsing, and what is being recommended in this issue. The Overlay module is designed for an entire admin page overlayed on a regular site page, while modal dialogs are for focused and partial interaction (perhaps the UX folks here can explain this distinction better, or maybe I'm erroneously perceiving a distinction where there really isn't one). So, I think we have to keep evolving our work with modal dialogs separately from the Overlay module overlay, though we should make both as accessible as we can. If we want to, though, we can decide to automatically disable and degrade modal dialogs when the Overlay is disabled. Do we want to do this though? I'm pretty sure there's people who would want Overlay disabled, but modal dialogs enabled.
Comment #25
Bojhan CreditAttribution: Bojhan commented@effulgentsia Having gone through the process of trying to make the overlay accessible, I am very worried of any interaction that requires a modal dialog to function (to note; Drupal, currently does not). It's clear from that process, that it is not possible as of now to make a modal dialog completely accessible - this due to "old" screenreader technology not recognizing its existance propperly. When you are talking about gracefull degegration of modal dialogs? What does this mean?
@Noyz I agree, we should focus on 1. Do you have any ideas for this interaction to exist inline? (for example search, rather than browse).
I would love to have a more indepth discussions on the useage of modal dialogs, it seems like a very interesting pattern to use - but also one that is a shift from our current UX strategy to keep functionality inline as much as possible.
Comment #26
Everett Zufelt CreditAttribution: Everett Zufelt commented@Bojhan et al
#1175830: Update to jQuery UI 1.10.2
Comment #27
joachim CreditAttribution: joachim commented> 1. We're asking users to remember paths in order to connect a menu to a node. Most users will not even look at the path let alone remember it
Are we? You can just edit the node and create its menu item through the node edit form.
There's a nice little module in the git applications issue queue that has an improvement to the UI for this: http://drupal.org/node/1081128
Screenshot:
Comment #28
webchick"You can just edit the node and create its menu item through the node edit form."
Yes, and that works, if:
1. They arrive at content first, before structure, which many don't (think Dreamweaver, etc. where you create your "sitemap" first before laying down content).
2. They actually see that checkbox on the node edit form at the time they're creating their content, which data shows about half the people do not.
3. They understand that checking that box adds it to the menu (or even what a menu is).
Jeff's mockups here are to support the people who didn't see / didn't know to check that box in the first place, and now have a bunch of pages they can't actually get to. This happens a lot, and has been verified over and over in testing across multiple Drupal versions. We call it the "node orphanage." :)
Comment #29
pjcdawkins CreditAttribution: pjcdawkins commentedIs there a good reason for choosing the text "Add link"?
Why not "Add menu item"?
The word "link" to me suggests something that could appear anywhere in the text of the page, whereas this is only about the menu.
I could imagine an editor wanting to add a normal hyperlink in some content, and thinking that she should look for the "Add link" page she saw previously.
Comment #30
joachim CreditAttribution: joachim commentedSo if we want to support structure-led site building, how about this:
- remove the path validation from the menu item creation form
- instead, have this process:
1. user creates a menu item (+1 for calling them menu links, btw!)
2. path points to something which does not exist
3. user is redirected to a confirmation form which says: 'There is no content defined to be found at path 'foo/bar'. Do you want to create a basic page at this path?'
Obviously with better verbiage. But there is a concept that new users must acquire, which is that in Drupal things 'live' at a path, rather than they 'are' that path.
Comment #31
rcross CreditAttribution: rcross commentedSomething worth noting that we've had a few recent examples of is the confusion around putting an unpublished node into the menu and having it not show up.
Perhaps this is a help text improvement or maybe a validation warning or something else, but I'm sure this would also help usability.
Comment #32
dcmistry CreditAttribution: dcmistry commentedI did some testing and found the same problem where new users did not know how to get the path while creating a menu item. This thread is certainly helping to inch forward. Link to the issue: http://drupal.org/node/1123662
Comment #33
eigentor CreditAttribution: eigentor commentedJust wanted to mention that there is already a module implementing the structured menu creation through the node form.
It is just having a bit of trouble with an inconsistent (no draggable items) interface.
http://drupal.org/project/menuux
Maybe this can be of use as a source of inspiration.
Comment #34
Peter Törnstrand CreditAttribution: Peter Törnstrand commentedSubscribe
Comment #35
bleen CreditAttribution: bleen commentedCan someone please clarify the state of this ... is the agreed upon direction of this issue to
a) improve the menu edit form by allowing people to search for content (a la the orig post & #13)
b) allow people to create menu items (menu links ++) that point to non-existing content (and perhaps warning them about that and directing them to create something by "clicking here"
c) both
d) neither
I'd love to help here as this is something that I have personally struggled with since D5. I often end up creating my primary navigation menu by creating 10 links to http://www.google.com and then changing them later. In my opinion I think that #13 is an excellent suggestion but clearly it does not help the person who goes to create his/her menu first. That is the bigger WTF than "how do I figure out what content I can link to." I like the suggestion in #30 ... anyway, if someone can clarify or summarize I think that would be helpful.
Comment #36
mgiffordSubscribe
Comment #37
bleen CreditAttribution: bleen commented@mgifford ... There is a miraculous new "follow" bottom at the top right of this issue. DEATH TO "subscribe"
Comment #38
mgiffordYikes, it's finally arrived! Thanks @bleen18
For that matter to be able to unfollow is pretty keen too. Thanks everyone who was involved in the upgrade. Nice changes to d.o lately!
Comment #39
jenlampton@webchick I used to build Drupal 5 sites structure-first too. It wasn't until D6 that the path had to be *valid* before it could be added to the menu. see #1339364: Remove requirement that drupal path is valid when creating new menu item - Save and warn only. for a related issue on path field validation.
Also, the content browser looks awesome! But, it also looks like an over-overlay a-la views or panels. Do we have a way to tackle that in core yet? I want to help build this! :)
Comment #40
mgiffordSo is someone able to create a patch for this for D8? What's the next step to help this move along?
Comment #41
effulgentsia CreditAttribution: effulgentsia commentedTo implement the screenshot in #13 in core, we're still stuck on #1175830: Update to jQuery UI 1.10.2. So, possible next steps are:
The above might not be a complete list, so if anyone has ideas on what else can be done, please share.
Comment #42
eigentor CreditAttribution: eigentor commentedA very important part in Jeffs Mockup is the "find content" button. Hopefully autocompletes will be much faster in D8. I would put the find content first and make it autocomplete. Give it an "enter path manually" toggle and off we go.
Comment #43
Noyz CreditAttribution: Noyz commentedRe #35 goal is A.
For everyone else. How can we move form talking about the design, to building it?
Comment #44
xjmRetitling for clarity.
Comment #45
mgiffordAdding tag for sprint
Comment #46
cleaver CreditAttribution: cleaver commentedI've been looking at this as part of the accessibility sprint. For my own purposes, I have summarized the main points below:
The dialog/overlay issue is something that needs to be solved. It seems like there may also be a need for a reusable browser UI component. In this case, it is browsing for path, but a node or entity browser will be useful (comment 3).
The accessible dialog issue needs to be solved for this to get to core. I think this would best proceed as a contrib module until that is worked out
Another issue I can think of is that we tend to assume a page is a node. My take on the layout initiative is that a page maps to a location which could be pulling in node(s) or other content sources. This would be a consideration for the browser, IE: you could be browsing a node with a title and body, but you could be browsing a "layout" of some sort that would be pulling in multiple entities. Even in D7 this could be an issue—for example, you might browse for the path "/news" which is actually a view without an author or body to display in the browser.
Comment #47
David_Rothstein CreditAttribution: David_Rothstein commentedI don't think modal dialogs are necessarily a blocker for this issue. It should be possible to have the browser inline rather than in a separate dialog (e.g., something like how Entityreference Browser does it, perhaps).
The browser could be hidden until the appropriate "Browse" link is clicked, of course.
Comment #48
cleaver CreditAttribution: cleaver commentedI like the idea of an inline browser. Looking at Media browser, if you tab off the browser, the focus moves to the obscured parts of the DOM. Once I did that, I never seemed to be able to get back to the browser. Also, I could not seem to tab to the "Cancel" link.
Comment #49
mgiffordWhat is it going to take to get a patch we can start reviewing for this?
Comment #50
eigentor CreditAttribution: eigentor commentedHm I doubt this will happen. Too much other stuff in the pipeline and this one does not even have a solid conception. My bet is contrib for D8.
Comment #51
webchickI think we can more properly categorize this as a task, rather than a feature. This trips up every single user in every single usability test ever. We should fix it.
Comment #52
mgiffordSo this isn't restricted by the feature freeze, but we still do need a patch to review.
Anyone able to take a look?
Comment #53
mgiffordtagging.
Comment #54
tkoleary CreditAttribution: tkoleary commentedMoving to D9. This is a feature request and we are past API freeze.
Comment #55
klonosI don't see Content Menu mentioned in this issue at all. Here's how it does things...
Adding a menu item that links to existing content (other options include a plain URL/path, a "Dummy" no-content node, or New {content_type}):
Here's how you edit existing menu items content directly from the menu management form and how you link to a new page. All content types configured to allow menu items are added in the "Target" drop-down menu in the form of "New {content_type}" entries:
The little pencil icon next to each menu item label allows to edit it in place.
And here are the actual steps in creating a new menu item that links to a page and also creating that page:
Comment #56
tkoleary CreditAttribution: tkoleary commented@klonos
That module is very nice and does quit effectively address the problem. Is there a D8 branch?
Comment #57
klonosYep, it actually more or less implements what is proposed in the issue summary but for D7. Combined with Special Menu Items that allows inserting the special
<nolink>
or<separator>
tokens as the menu item path it also addresses the need to create "empty"/placeholder menu items. So people can first easily create a scaffold of their menu structure before they start populating/linking to actual nodes.Here's a couple of issues I've recently filed in it queue that'll make the module perfect (the maintainer currently has no time to implement these, hence postponed):
#2042227: Replace the node menu settings tab with a minimal instance of Content Menu.
#2039267: Support the Instant Filter module when installed (for searching content on the add_existing_content page).
#1597620: Support the special_menu_items module (if installed) for creating empty (<nolink>) & separator (<separator>) links.
There is no 8.x branch available that I know of: https://drupal.org/node/1549778/release?api_version[]=7234
Comment #58
webchickClosing this in favour of #1123662: Participants did not know how to get the path while creating a menu link, which has a patch.
Comment #59
webchick