Topic on Talk:Compact Personal Bar

I was surprised to notice that my existing user scripts were immediately compatible with the compact personal bar, so I looked into the structure, expecting to find new IDs.

I found that instead, portlets are hijacked from within mw.util.addPortletLink:

if (portlet !== 'p-personal') {
    return addPortletLinkOld.apply(mw.util,arguments);
}

While I appreciate the value of reverse compatibility, my first thought with the compact personal bar was personalizing it with JS, and this interferes with that. The new mw.util.addPortletLink function also drops the useful "nextnode" argument; it seems odd to break some functionality while providing reverse compatibility elsewhere.

I'm concerned that beta functionality too often makes the bad assumption that users won't make mild modifications to parts of the interface. Usually it's easier to update my code or add workarounds than to complain: I certainly don't want to hold up big usability improvements in the name of tweaks for power users. In this case I think it's worth complaining: why is this key function being broken like this?

Nihiltres, I can't answer from the technical perspective, but we can ping Juliusz the development lead on the project.

Nihiltres: At the hackathon we discussed that we really need a new api for 'placing' content. one that can be implemented 'per ui/skin' but is consistent across all of them and allows for hooks for users to attach their own functionality. Something like mw.ui.chrome.

Were a long way from that though.

I ignored nextnode as it seems like a very fragile way of indicating where something should be placed. Also, in compact personal bar, we're not allowing for as much flexibility when it comes to gadgets and user scripts. All custom items go to a single group in the menu, which means that nextnode would have to be an item from that same group. Since all the items in this group are added by gadgets and user scripts, there's no way of knowing what might be in there already.

Juliusz Gonera: My problem is with statements like "we're not allowing for as much flexibility when it comes to gadgets and user scripts". You don't get the option to restrict user scripts. Users like me will still customize the interface, just now we'll have to duplicate the old behaviour of mw.util.addPortletLink instead of using it directly—defeating the purpose of the function as a standard. That's a bad situation.

User scripts that change UI are inherently fragile because they make assumptions about the structure of the page, a problem only resolvable by something like the "mw.ui.chrome" idea that TheDJ mentioned above. Until something like that is implemented, standard functions like mw.util.addPortletLink shouldn't for any reason be limiting user script behaviour—they should offer flexible behaviour with decent fallbacks ("nextnode" being an example). I'm willing to tolerate some redirection in the name of backwards compatibility, but there needs to be a way to bypass that behaviour if it's explicitly requested.

Nihiltres, I think what Juliusz means is that we're trying to allow for customization that fits within the system rather than making it really easy (and helping to enable) people to break things all the time, which is the current state of things. A lot of the initial "bugs" on compact personal bar were actually people who had gadgets and scripts that were breaking CPB rather than CPB breaking the gadgets and scripts.

"I'm going to build my own addPortletLink! With blackjack! And hookers!"

But more seriously, I did implement my own addPortletLink. It behaves similarly to the default one, except it takes its arguments in an object. It even emulates CPB's hijacking behaviour, except when the object has a property ignorefilters with a truthy value. This is the sort of behaviour I'd like to see.

Nihiltres: So you basically would like addPortletLink to not ignore the next argument if a special flag is set but ignore it by default?

Jaredzimmerman (WMF): Would allowing custom position for gadget links if someone really insists (sets a flag) be acceptable from the design point of view?

Juliusz Gonera & Nihiltres My worry is that we're just setting developers up to have to do another rewrite soon. If we suggest (in code) that the icon area with Messages, Notifications, and Watchlist is a good place to put new items, and then this changes again with future updates like Winter I don't think we're setting good expectations. I'd love to learn a bit more about why the gadgets area of the flyout isn't an acceptable place to put these items so we can think of other ways to help that will be safe and stable longer term.

Juliusz Gonera & Jaredzimmerman (WMF): I'm not so much worried about the next argument as I'm worried about the portlet argument.

To address Jared's concerns in particular, i.e. "why the gadgets area of the flyout isn't an acceptable place to put these items": most obviously, the contents of the flyout aren't visible by default. Certain gadgets (e.g. the clock ones) may only make sense if they place content visible by default. Another concern is relative position: one of my user scripts adds a personal link to the log of the user's (non-edit) actions, and this is best placed adjacent to the contributions link because of their similarity. Someone might want to add a gadget that adds its own notifications-like system, even … and none of these examples are compatible with the behaviour I've highlighted here. There ought to be a "safe", standard way to do these things, and failing that, I'd rather fragile (but standardized) code over an implicit ban on "unusual" gadgets/scripts. Design should guide gadgets & scripts rather than circumscribe them.

As a better system, we might focus on supporting intent. My implementation of addPortletLink does a really basic version of this: it filters things for the user in a "safe" way by default, but if the user explicitly says so, it'll use exactly the parameters with which it's provided. A better implementation could be as simple as adding skin-specific variables for the "default" places to put content; offhand I imagine replacing portlet: $("#p-personal") with something more like portlet: mw.ui.elements.intent("personal"). That example's simplistic, but I figure it shows a good direction we could go.

Nihiltres I can't speak to the technical parts of your comment, I'll let Juliusz do that. But as I said before, it isn't about control or prohibition of what people can and can't do, rather by saying… "here is what you should do, also here is how to circumvent that and do something less than Ideal, here is how to do that" sets up different expectations. E.g. if a developer knows what they are doing is hacky and broken there is less of an expectation that it won't just break when things change or are updated. People will do what they want, we can't stop that and aren't trying to, but we want to set everyone up for success, and enabling people to do thing that may quickly break doesn't seem like enabling people for success.

To your specific point about a place for things that need immediate visibility, and are not inside a flyout. we can do some more thinking about that. Thank you for a use case to work with.