Add layout nodes as first rather than default child by default?

[Andrew Petro]

Local use case: users search, find some awesome app, and click add-to-home to add it to their layout. Which in MyUW is implemented as a single tab.

Where should the item add? As the first or last item on that tab?

Well, so far MyUW has used a naive user preferences update call that specifies the target tab as the parent but doesn't specify which child element to place the new portlet subscription in front of. So it gets the default behavior of adding it to the end.

UX feedback suggests that instead we should be adding these items to the top. Which makes some sense -- prioritize the thing with the most novelty, it's probably most immediately interesting to the user and top-adding it will probably help them notice that it's successfully added whenever they leave the search results and re-view their home screen. Fair enough.

So I think I have the local patch that will implement this change. I changed the default behavior locally. 

Another approach might be to simply make the front end interrogate the layout to determine the ID if any of a first child node and then call the preferences update specifying to place the new item before that, but I'm trying to avoid making the front end more dependent upon implementation details of the back-end. From the front end's perspective this is just "Add nsse-survey to the layout" or so, it's a back-end implementation detail that this involves digging around in DOMs looking at child Nodes.

Yet another approach might have been to introduce a new web service with the simplicity I'm looking for that in its implementation does the layout inspection and nuancing the call to the user layout manager. That way the back-end implementation details wouldn't seep into the front end, and yet I wouldn't have to hack the default down in DLM and could instead front this in yet another Controller or so. Could.

Went with the approach I did, first stab at least, because it seems like at least in MyUW we really do want to change the default. It's not that we want to default to adding to the top for this one edge case. It's that, no, really, whenever the user adds something and we don't know where  to put it, default to putting it first. So hacking the default seems most expressive of that insight and so simplest.

Question: whether and what ought to be done in upstream with this patch? Anyone dependent upon the add-as-last default behavior? On reflection most other adopters would prefer it add-as-first instead too? Ought this default behavior to be configurable per uPortal implementation, perhaps? No one else wants this changed?

I'm not thrilled about yet another local tweak further forking MyUW from upstream. I also figure if top-adding turns out to be a better user experience hereabouts in MyUW it's probably a better experience in other uPortals too. So if changing the default behavior seems like a good call to anyone else, I'd be inclined to offer that changeset for uPortal 5....

-Andrew

[COUSQUER Christian]

Hello Andrew,

 

You’re not tacking of uPortal 5 Respondr, you’re talking about the portlet Favorite don’t you ?

Because the default behavior in uPortal 5 Respondr to add a Layout node is already top-adding.

 

Best

Christian Cousquer

Software Engineer – uPortal (Respondr) Admin

Apereo uPortal Steering Committee Community rep.

Esup Consortium

UPMC – Sorbonne Université

Direction des Systèmes d’Information

Pôle ‟ Études & Développements ” – ‟ Web - ENT - Authentification ”

Tour 33  34 – 4ème étage - Bureau 415 - Boîte courrier 171 4, place Jussieu

75252 PARIS CEDEX 05 FRANCE

Tél. :       +33 1 44 27 83 04

Mob. :   +33 6 80 62 41 08

Fax :       +33 1 44 27 61 34

Mail :     christian...@upmc.fr

 

 

 

De : uport...@apereo.org [mailto:uport...@apereo.org] De la part de Andrew Petro
Envoyé : mardi 2 mai 2017 05:17
À : uPortal Developers <uport...@apereo.org>
Objet : [uportal-dev] Add layout nodes as first rather than default child by default?

--
You received this message because you are subscribed to the Google Groups "uPortal Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uportal-dev...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/uportal-dev/.

[Drew Wills]

I agree that the more sensible default is to add it as the first element.

+1 for changing the default behavior.

We should, however, probably honor DLM restrictions if we're using this
API to add a content item to a fragment tab.

drew

[Drew Wills]

On 05/02/2017 12:08 AM, COUSQUER Christian wrote:
> You’re not tacking of uPortal 5 Respondr, you’re talking about the
> portlet Favorite don’t you ?
>
> Because the default behavior in uPortal 5 Respondr to add a Layout node
> is already top-adding.
>

Good point.

I thought that was the case.

drew

[Andrew Petro]

No, I'm not talking about not-yet-released uPortal 5 Respondr. MyUW is on (forked) uP 4.2.1. MyUW is not using the XSLT rendering pipeline in a way that end user preferences modify. (Exclusively renders maximized / exclusive portlets -- no opportunity to add or re-order.) Even if we were using Respondr in a relevant way, we've forked Respondr so hard (renamed "Bucky", even) that our experience might not relate anyway. :/

But I think there's something more interesting going on here: I'm talking about what the default behavior should be down in the layout manager, regardless of front end. Favorites, Respondr, uPortal-home, uMobile, ... What should the layout manager do when it's asked to add a child to a parent with the sibling order left unsaid? And I think where we're getting is that the layout manager should default to adding it as a first child when it doesn't know what order to put it in.  Sensible default. Might simplify Respondr, favorites, uPortal-home, uMobile, ... in the case where they want this behavior, and if they want to specify in what order to add the child, can still do that by more precisely specifying destination.

In the details, part of what's going on here is we're finding we want to be able to add/remove items by fname rather than by subscribe ID because doing so reduces how much the app directory or the widget directive needs to know about the implementation details of the user's layout. Simplifies the front end code and makes it less fragile. Also takes some tiny steps towards setting the stage for a new layout manager implementation that fulfills the simpler APIs.

I'll take a TODO to make a port of this patch for upstream ( Jasig/uPortal). Might discover interesting differences when I get to that, and yes, the version in upstream will need to honor DLM restrictions. It'll land in a Pull Request, but probably not today.

-Andrew

[Andrew Petro]

Alright, I've tried this a few ways. Had a hairball scheme for trying to add as first and then falling back to adding as last, that got weird. Latest attempt got close but I've realized it breaks deliberately adding a node to end. Next move is to give up on changing the *default* behavior and just add a new endpoint that better expresses wanting to accept a default sibling order.

Did a little refactoring on the way I think makes it easier to understand what the current code is doing.

Which leads to this:

Anyone know why fragment owners aren't allowed to add nodes? I found that surprising. Don't uPortalers log in as layout owners and add nodes all the time when editing DLM fragments through the admin UI? Clearly either or both isFragmentOwner or canAdd() don't mean what I think they mean. :)

-Andrew

On Tuesday, May 2, 2017 at 9:36:48 AM UTC-5, Andrew Petro wrote:

...