When configuring WYSIWYG profiles (/admin/config/content/wysiwyg/profile/[name]/edit) with IMCE WYSIWYG bridge enabled the IMCE label in the Buttons and plugins section is a link to http://drupal.org/project/imce

This is poor usability because it makes the label useless. The common user expectation is that clicking the label would check the checkbox, in this case the user is taken to drupal.org without any warning. The user is likely to be well aware of what IMCE is given that they have installed it already.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

skwashd’s picture

Status: Active » Needs review
FileSize
1.31 KB

The attached patch fixes this in 7.x-1.x-dev using current CVS.

sun’s picture

Title: IMCE label linking to IMCE project is poor usability » Plugin/button label linking to project homepage is poor usability
Project: IMCE Wysiwyg bridge » Wysiwyg
Version: 7.x-1.x-dev » 7.x-2.x-dev
Category: bug » task
Issue tags: -ux +Usability

Needs to be fixed in Wysiwyg instead.

skwashd’s picture

I don't see why this needs to be fixed in WYSIWYG, the issue is with how the bridge prepares its label.

The attached patch deals with the problem in the bridge.

TwoD’s picture

The patch does not fix the usability problem you mention, it only avoids it by removing the URL stating where the plugin originates from. That information should still be there so Wysiwyg can inform users of this. A better approach would be patching Wysiwyg to not turn the labels into links - which is done for any plugin wrapper providing an URL - and show the link somewhere else.

skwashd’s picture

The attached patch moves the fix into WYSIWYG. When the URL is specified it will display "Visit project page." as the #description for the checkbox. I have only tested it with IMCE and couldn't find any WYSIWYG button plugins for D7.

Unlike the the existing code, this version opens the link in a new window. I am not sure this is the best idea, but it keeps the intention of the existing code.

helmo’s picture

I tried to re-roll this patch but ran into a problem.

I saw no effect from the #description attribute you are adding.

To get a similar result I now append a link to the #title attribute.

This results in something like: [] IMCE (project page)

rocketeerbkw’s picture

I've rerolled against 7.x-2.x HEAD and moved links back to checkbox #description.

Show buttons links below button names

helmo’s picture

@rocketeerbkw: your new patch is missing the 'attributes' => array('target' => '_blank') part.
Are you opposed to using that?
I had also added 'title' => t('Visit project page.'), but that's less important ...

rocketeerbkw’s picture

I am (not strongly) opposed to target=_blank. It doesn't match the convention in other areas like the WYSIWYG Installation Instructions where links to editors open in the same page and on Available Updates "download" and "Release Notes" open in the same page.

If the Links were next to the button name, I would keep "Visit project page," but now that they're on a separate line I think it's better that you can see the actual URL (this is a usability patch after all).

helmo’s picture

I had "Visit project page" as title attribute, not the link text. Showing the url is indeed a good thing.

TwoD’s picture

The patch looks good and I like seeing the URL, as that should clearly indicate you are not going to stay within the site if you click that link. I just hope they won't become too long. Do we need to implement shortening of the displayed url or is that overkill?

I think the main thing that makes this form different from the forms on Installation Instructions, Available Updates, etc, is the sheer number of options you'd potentially have to go over again if you haven't saved before clicking the links. The amount of checkboxes does increase the risk of hitting a link by mistake. On the other hand, I don't like links which open in new windows by default either.

rocketeerbkw’s picture

@helmo ahh I missed the title attribute, I thought you were talking about the (project page) link text. I guess I don't think it's necessary anymore with the link visible. And any URL can be placed there, could be to someones homepage, not a project page.

@TwoD I was on a 900px wide monitor when I took the screenshot and I didn't think they were too long. What I hate about truncating is seeing a bunch of http://drupal.org/project/... links. Since the most important bit of d.o links is at the end and the most important part of any other link is the beginning.

I could be convinced to open links in a new window if it's better UX on a settings page.

TwoD’s picture

I was thinking about shortening them more like http://drupal.org/.../wysiwyg, to keep both ends intact, but yeah, that is starting to sound more like overkill anyway.

So, to open or not to open in a new window? If we can't decide or argue for or against, let's just leave it the way it is and wait for someone with a stronger opinion. ;)

helmo’s picture

Status: Needs review » Reviewed & tested by the community

Lets indeed keep the link behavior like it is.
When we change that we should also change it in the Installation Instructions, so it would warrant a separate issue.

sun’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for reporting, reviewing, and testing! Committed to 7.x-2.x.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Status: Fixed » Closed (fixed)
Issue tags: -Usability

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