That all sounds very reasonable, but just checking back on the QA overhead issue that began this thread...will there be significant impact during the 1.4 release if we leave the carousel in place?
= nate On Jul 2, 2012, at 10:49 AM, Nicolaas Matthijs <[email protected]> wrote: > Thanks for all of this input. > > I must confess that I like the carrousel widget as well, and I'm happy to > read that we all value the goals behind it. However, I also think we agree > that the way in which it has been conceived has not been a success, mostly > because of its position in the UI and the rotating movement. > > It was always the goal to design and build a new "Suggested stuff" > widget/experience for 1.5.0 when suggesting to remove the widget from 1.4.0. > Given this and the fact that the implementation has got some implementation > issues, I think it's probably best not to add it to the Widget Library, > especially because the data feeds it's using will still be available. > > However, given the responses on this thread so far, I think we might as well > keep the widget around until it's replaced by something more suitable in > 1.5.0. Institutions can still disable it if they don't want it ... > > Designs for the new widget will follow soon ... > > Hope that helps, > Nicolaas > > > On 29 Jun 2012, at 08:15, John Norman wrote: > >> I'm not sure I understand the amount of discussion this is generating. I >> probably don't understand the carousel well enough. >> >> It seems to me the concept of a dashboard gadget that is drawing your >> attention to content that is potentially of interest to you (individually) >> is a good one. A key factor in user perceptions will be how well it finds >> things that are of interest and that you would not otherwise have found. >> However, good it is there will be some people who don't want it and it >> should be possible for them to disable/hide it. My guess would be that most >> reactions are negative for one of two reasons; either they don't see it >> bringing really pertinent content to their attention, or they don't like the >> way it presents that pertinent content (on a conveyer belt). I suspect that >> as our algorithms improve for identifying relevant content, perceptions may >> change. But I'm not sure we have resources (or even perhaps critical mass of >> content/activity) to work on such improvement ATM. >> >> Resource constrained as we are it seems reasonable to set this one aside for >> a bit, but I don't think we should abandon it or the concept that it seeks >> to address. If it is easy to move into the widget space, that seems like it >> would be a good idea. >> >> My 2c. >> >> John >> >> On 29 Jun 2012, at 07:42, Buchan, Janet wrote: >> >>> Confession: I didn’t like the carousel widget until Lucy outlined their >>> potential use of it & others the original design goals. I am not sure I >>> like the carousel as it is (CSU will disable the carousel for our upcoming >>> pilot) but would like to have that functionality down the track. I support >>> Nate’s comments: >>> >>> >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. >>> >>> Perhaps the reaction is to the carousel as a ‘push’ strategy, unable to be >>> controlled by the user, and users may want more control which they may get >>> through Explore features (sending carousel it to the optional widget level). >>> (Of course many of our CLE users are still at the stage where they don’t >>> see a wiki or blog as personally relevant until it is built into their >>> learning experience!) >>> >>> Janet >>> >>> >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Jon Hays >>> Sent: Friday, 29 June 2012 2:28 PM >>> To: Sakai OAE User Reference Group >>> Cc: Bert Pareyn; Sakai OAE User Reference Group; >>> [email protected][email protected] >>> Subject: Re: [oae-urg] [oae-dev] Carrousel widget >>> >>> I like your analogy Lucy. I think the reason it is so negatively viewed by >>> our users is that it just didn't make sense to them as THE highlighted >>> feature of a person's "personal" dashboard. It is seen as a distraction >>> rather than a source of anything personally relevant. >>> >>> Jon >>> >>> Sent from my iPhone >>> >>> On 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 > > _______________________________________________ > 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
