Thanks for reminder of our project design goals...we probably do not return to those often enough.
So clearly, almost no one includes the carousel in their production environment, so it likely makes sense to turn it off, remove it, and if it makes sense, let it live out its life in the widget library. I'm fully supportive of the idea that we would try experiments to achieve our design goals, and discard them if they are not working out. I'm less convinced that we have a good idea of other ways to achieve the underlying goal—activity streams as we just discussed them seem just as likely to not be immediately useful to people expecting the status quo as the carousel. I'd like to support a practice where we consciously address new ways to achieve a goal as we discard earlier experiments—or, we reprioritize the goal itself. I sense (and share) a general shift in priorities away from new paradigms to meet more familiar goals, but always think we should balance these priorities. If our only goal is to make a shiny new LMS, we already lost that race. I find it a bit disconcerting that the people I've heard talk about the carousel that are focused on new learning paradigms are attracted to it, but have had trouble finding ways to fit it in. If we spent the resources to take the carousel this far, the goal it was attempting to serve must have been important enough to warrant them. Just a vote on removing the carousel devalues the resources we already spent if we don't also consciously address why it was there and how that need fits into our planning. So, I say if we are going to make an eve-of-release decision to remove a capability that was designed to meet a specific design goal, that decision should be accompanied by a tangible process to readdress that goal: reprioritize the goal (eg, downward) or shift the focus to a new experiment. As for the carousel moving to the widget library: if we don't believe in it and are not ready to put resources into supporting it, is the library the right place for it? I support the idea of a library that includes experiments that did not (yet) pan out, but given the current, small catalog in the library, what is the stature of something living there? Perhaps we should ensure there are reviews/explanations of widgets, so potential adopters have some context. = nate On Thu, Jun 28, 2012 at 10:51 AM, Clay Fenlason <[email protected] > wrote: > Not only are you not alone, it's written into our expression of the > design goals for the project [1] > > But I think we need to distinguish the operational decision of how to > handle things in 1.4 (QA efforts, default configuration and all the > rest) from a discussion of how we're going to meet that goal by other > means. I think that latter discussion belongs on the URG agenda, but > it will take more time. > > ~Clay > > [1] https://confluence.sakaiproject.org/x/lYYpB (See #3 under > 'functional emphases') > > PS I also have tended to like the carousel. I suggested to Sam at one > point that we should be making the Open Carousel Environment. I think > he threw something at me. > > On Thu, Jun 28, 2012 at 1:08 PM, Nate Angell <[email protected]> wrote: > > While I'm not against removing the widget from the build and putting it > in > > the widget library, I'd still like us to spend a bit of time talking > about > > how else we are thinking to address the goal of enabling people to make > new > > connections. > > > > As it stands now, I feel like the related content widgets do some of that > > work, but do not surface to users in a very dramatic way. > > > > I'm assuming that I'm not alone in wanting to support a goal of enabling > > people to make NEW connections with content, people, and experiences? > > > > = nate > > > > On Thu, Jun 28, 2012 at 9:58 AM, Lucy Appert <[email protected]> wrote: > >> > >> Confession: I actually LIKE the carousel widget (I feel like this is the > >> social equivalent of saying I read the NY Post for the news but anyway > :-) ) > >> and I can see it being used effectively in some of the cases we've got > in > >> our pilot. For example, we are going to have 800 student submissions to > a > >> portfolio prompt that we'd like for everyone in our program (around 2500 > >> people) to be able to look at, recommend, comment on. The carousel > widget > >> would be a fabulous way to randomly surface the content in that > collection > >> of submissions. So even though it looks like it's dead for now, I'd > love to > >> keep the carousel widget around so that we could figure out ways to > employ > >> it in cases like this one. > >> > >> Lucy > >> > >> > >> On Thu, Jun 28, 2012 at 12:48 PM, Clay Fenlason > >> <[email protected]> wrote: > >>> > >>> On Thu, Jun 28, 2012 at 12:36 PM, Eli Cochran <[email protected]> > >>> wrote: > >>> > -1 on putting into the widget store. It is (IMHO) of marginal utility > >>> > and I > >>> > worry that it complex enough that supporting in the widget store will > >>> > become > >>> > a distraction when there is other work to be done. > >>> > >>> I don't understand this objection. Is there an expectation that the > >>> team will maintain widgets in the widget library? I didn't think so, > >>> and was assuming the widget library included enough information on > >>> versioning, etc., that the end-deployer would have to take into > >>> account. > >>> > >>> ~Clay > >>> _______________________________________________ > >>> oae-urg mailing list > >>> [email protected] > >>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg > >> > >> > >> > >> > >> -- > >> ____________________ > >> Lucy Appert, PhD > >> Director of Educational Technology > >> Liberal Studies Program > >> New York University > >> 726 Broadway, Rm. 677 > >> New York, NY 10003 > >> (212) 998-7168 > >> [email protected] > >> > >> _______________________________________________ > >> oae-urg mailing list > >> [email protected] > >> http://collab.sakaiproject.org/mailman/listinfo/oae-urg > >> > > > > > > _______________________________________________ > > oae-dev mailing list > > [email protected] > > http://collab.sakaiproject.org/mailman/listinfo/oae-dev > > >
_______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
