Hide slug text box by default

REOPENED
Unassigned

Status

developer.mozilla.org
Editing
REOPENED
6 years ago
4 years ago

People

(Reporter: openjck, Unassigned)

Tracking

Details

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

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

6 years ago
Created attachment 639825 [details]
Kuma approach
(Reporter)

Comment 2

6 years ago
Created attachment 639826 [details]
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.

Comment 4

6 years ago
on the list for post-launch
Blocks: 756266
Priority: -- → P2
(Reporter)

Updated

6 years ago
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...
(Reporter)

Comment 6

6 years 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! :-) )
(Reporter)

Comment 8

6 years ago
(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.
(Reporter)

Comment 9

6 years ago
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.
(Reporter)

Updated

6 years ago
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.
(Reporter)

Comment 14

6 years ago
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
(Assignee)

Updated

6 years ago
Version: Kuma → unspecified
(Assignee)

Updated

6 years ago
Component: Website → Landing pages
Product: Mozilla Developer Network → Mozilla Developer Network
Duplicate of this bug: 777822
(Reporter)

Updated

6 years ago
Component: Landing pages → Editing
Whiteboard: u= c= s= p= → u= c=Editing s= p=
(Reporter)

Updated

6 years ago
No longer blocks: 756266
(Reporter)

Updated

5 years ago
Whiteboard: u= c=Editing s= p=
(Reporter)

Updated

4 years ago
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
Last Resolved: 4 years ago
Resolution: --- → INVALID
(Reporter)

Comment 17

4 years ago
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.
You need to log in before you can comment on or make changes to this bug.