AP> User re-ordering of the portlets in the home screen will be disabled to reduce technical risk and support burden. Drag-and-drop as trip hazard. This feature probably comes back in on some subsequent release.
AC> Trip hazard? Trip hazards are those dangly bits of the implementation that you’re probably going to trip over and hurt yourself, and when you do you say a few choice words and curse yourself for not having cleaned up the hazard before you tripped over it. [1] Drag and drop is, arguably, a trip hazard. Where I think we ended up at MyUW from the design sprint is that for us, we’re arguing it is such a trip hazard for now. Drag-and-drop * Requires fancy JavaScript which drags in browser support issues * Requires JavaScript dependencies that we may be able to avoid by dropping the whole drag-and-drop feature set. Hey, might be able to drop Fluid entirely :) * Requires DLM handling of per-user re-ordering directives to work * Collides with whatever we’re going to do to handle the case of providing appropriate default favorites to students and staff and users who are both students-and-staff. * Has accessibility issues, unless it doesn’t, which requires validation. This isn’t to say that drag-and-drop can’t be implemented successfully. This is just to say that it adds risk and distraction and the tradeoff of not dealing with this in favor of dealing with other priorities is a good one to be making. Let’s see how bad the experience is with users unable to re-order the items they slurp into their home screen and add drag-and-drop informed by that user testing and feedback. But hey, it’s a moving target. "Embrace change" and all that. Drag-and-drop could come right back in. Kind regards, Andrew [1]: You know, like that suitcase from the Apereo conference that’s still on my bedroom floor that I trip over in the dark getting ready for work each morning. On 8/7/14, 5:50 PM, "Anthony Colebourne" <[email protected]<mailto:[email protected]>> wrote: Andrew, Thank you for being so open, the community is so much richer for it. My opinions inline... On 07/08/14 20:29, Andrew Petro wrote: * *Collections of Favorites are gone*, at least for now. [1] This is devastating news :-( * User-selected *Normal Window State portlets living on the landing tab are back in*. This means that Maximized isn't the only way to get at user-selected stuff; portlets are sometimes in Normal Window State rather than only Maximized. Woo Hoo! * Favoriting a portlet and adding it to one’s Welcome page (the only page of multiple portlets) is exactly the same thing. *So, you favorite a portlet, and that adds it in Minimized window state right on your home screen. * You might then expand it to Normal window state, and that expansion will be remembered. Love the use of minimized window state. * *Minimized window state will have a styled infocard-like representation.* Title, first bit of the description, icon. Enough to evoke what it is so you can decide to open it. Will this be actually rendered portets or just skin trickery from marketplace registry? I hope its the former, portelts have a lot to offer. Perhaps it could source and aggregate some marketplace content too via an API. * User *re-ordering of the portlets in the home screen will be disabled* to reduce technical risk and support burden. Drag-and-drop as trip hazard. This feature probably comes back in on some subsequent release. Trip hazard? * *Search is de-scoped to only search MyUW content*, and we’re dropping the whole search Portlet Event thing. No search of dynamic content, just search over descriptions and other static portlet publication metadata. *This will make search radically faster.* It also probably makes search implementation radically different in that, at least for the near term in redesigned MyUW, *Search is just another view on Marketplace*. It’s entirely feasible to load the entire (filtered-for-the-user) portlet metadata registry down into the browser and perform all the search operations client-side. This will make search radically faster. Couldn't a hybrid solution be found? I believe autocomplete has already gone this way. Perhaps the initial render can be followed by ajax loading->loaded content search? (infinite scroller?) I see personalized federated search as a big selling point of uPortal. There must be ways we can make this performant (or at least appear so). We've spoken in the past about including a crawler, I feel there may be something in this. Also we spoke about the difficulties of personalized search in the absence of a PortletRequest :-( .... perhaps ajax is our friend? simple but effective. -- Anthony. -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
