Closed Bug 771679 Opened 12 years ago Closed 4 years ago

Hide slug text box by default

Categories

(developer.mozilla.org Graveyard :: Editing, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: openjck, Unassigned)

References

Details

(Whiteboard: [triaged][type:change])

Attachments

(2 files)

This one is up for discussion. I personally think it's a good idea, but others may not.

I really like the way Drupal handles options that probably-work-by-default. For example, the "machine name" of a field is chosen automatically based on the human-readable name that the user enters. If the user *really* wants to change it, they can click an "edit" box to do so.

It works well -- remove distractions for the 80% of users who are happy with the default, add a click for the 20% of users who aren't. I would love if we took the same thing with slugs.

See the screenshots.
Attached image Kuma approach
Attached image Drupal approach
I not only agree, but I don't believe the slug should be user-editable at all; instead, the move page option should handle this.
on the list for post-launch
Blocks: 756266
Priority: -- → P2
Summary: Hide slug text box by default → Do not allow users to edit article slugs
You have no clue how much time and ability-to-sleep this decision would have saved me 3 weeks ago...
We still need to have some discussion about this before we decide what to do, but I am sorry we didn't catch this feedback sooner.

Since I started, I have been very active in publicizing new features (https://wiki.mozilla.org/MDN/Milestones/2012-07-03/Review_and_Feedback) and getting users to test the software (https://wiki.mozilla.org/MDN/Feedback). As long as we keep doing that, we should see fewer of these late-in-the-game surprises.

The good news? If we were using a more plan-driven software process, we may not have realized this until much later.
Not sure about this one. I have used the ability to rename slug at least one time on Kuma.

Maybe we won't want users to have this ability, but probably we want trusted users/admin to have this ability.

(David Walsh: you hard work has been used in the real world! :-) )
(In reply to Jean-Yves Perrier [:teoli] from comment #7)
> Not sure about this one. I have used the ability to rename slug at least one
> time on Kuma.

What have you used it for? Maybe you and Sheppy can discuss the benefits/drawbacks of allowing users to do this.

> (David Walsh: you hard work has been used in the real world! :-) )

Absolutely! Your hard work is being used by anyone using Kuma. I wish we discovered this earlier, but I do think it's better to have this conversation now than ten months later.
Would this be an easy change? If so, it might make sense to take care of this now rather than opening the door for people to depend on this feature and then removing it later.
(In reply to John Karahalis [:openjck] from comment #8)
> (In reply to Jean-Yves Perrier [:teoli] from comment #7)
> > Not sure about this one. I have used the ability to rename slug at least one
> > time on Kuma.
> 
> What have you used it for? Maybe you and Sheppy can discuss the
> benefits/drawbacks of allowing users to do this.
To fix a typo in it. Even if we don't allow the users to do it, I think we, admins, should be able to fix them if needed.
Yes, only admins should be able to edit a slug. Moving a page should be a very discrete operation, which would replace editing a slug for other users. And it probably should also have a permission associated with it (although I would be fine tying it to the same permission that controls uploading files; I think those two operations are about the same level of trust, in terms of potential damage to the site.
Summary: Do not allow users to edit article slugs → Only admins should be allowed to edit article slugs
(In reply to John Karahalis [:openjck] from comment #0)

> I really like the way Drupal handles options that probably-work-by-default.
> For example, the "machine name" of a field is chosen automatically based on
> the human-readable name that the user enters. If the user *really* wants to
> change it, they can click an "edit" box to do so.

The problem is that variation between URL path (ie. slug) and display title is deeply embedded into existing MDN content. We need to support that going forward. We can't just derive a machine-generated slug from page title, and so have to allow the ability to manage both as pieces of user-generated content.

Users should be able to change slugs - even if "edit" is changed to mean "move". IMO, "move" is just a fancier method to "edit" a slug that also takes into account the effect slug changes have on site hierarchy.

Users should also be able to specify slugs on page creation, also taking into account site hierarchy. This is the work :davidwalsh has been doing.

So, yeah: Only admins should be able to directly edit a slug, and then only from the Django admin. Otherwise, in the future all slug edits need to be "move" operations per bug 764431
(In reply to Les Orchard [:lorchard] from comment #12)

> The problem is that variation between URL path (ie. slug) and display title
> is deeply embedded into existing MDN content. We need to support that going
> forward. We can't just derive a machine-generated slug from page title, and
> so have to allow the ability to manage both as pieces of user-generated
> content.

That said, we *do* derive a *suggestion* for slug from the title as it's entered. But, we can't altogether close off the ability to alter slugs, whether through direct edits or a move function per bug 764431.
Agreed.

That's what I was getting at with comment 0 and comment 1. The suggested slug may be good enough 80% of the time. The interface could reflect that -- editing the slug would be possible, but would be out-of-the-way most of the time.

Basically, we have two bugs in here: one about (maybe) simplifying the interface and one about only allowing administrators to edit bugs. I have reverted this title to reflect the original purpose of this bug and have split the administrator thing into bug 777822. The latter may be unnecessary of we decide to just treat renames as moves (bug 764431).
Summary: Only admins should be allowed to edit article slugs → Hide slug text box by default
Version: Kuma → unspecified
Component: Website → Landing pages
Component: Landing pages → Editing
Whiteboard: u= c= s= p= → u= c=Editing s= p=
No longer blocks: 756266
Whiteboard: u= c=Editing s= p=
OS: Linux → All
Priority: P2 → --
Hardware: x86_64 → All
Whiteboard: [triaged][type:change]
I don't think this is relevant now that we have page move, and I assert that users should have the right to set the initial slug.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
I agree that users should have the right to set the initial slug. I just think the form field should be hidden by default (see comment 2) since it's an advanced feature that most people won't use.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(In reply to John Karahalis [:openjck] from comment #17)
> I agree that users should have the right to set the initial slug. I just
> think the form field should be hidden by default (see comment 2) since it's
> an advanced feature that most people won't use.

Agreed.
Although I do think we need to do more to prevent mis-filing of pages. We should be confident that we're validating slugs well, and I'd like to consider adding a little more information displayed to the user about how to use the slug field, since it's not really obvious. Could even just be a link to a page about this subject.
MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.
Status: REOPENED → RESOLVED
Closed: 10 years ago4 years ago
Resolution: --- → WONTFIX
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: