[Building Sakai] [Management] Gradebook Situation
Mustansar Mehmood
mustansar at rice.edu
Fri Jul 30 11:12:34 PDT 2010
I couldn't agree more with the need to separate back end from UI as
much as possible giving teams to make a choice that fits their
experience and preferences in choosing the right framework.
For the major Sakai tools, teams responsible for developing and
maintaining those tools, are much more suited for making the appropriate
choices. However that system doesn't relieve the sakai community of the
need to have standards to make sure that short lived technologies don't
make their way into Sakai.
Tool support, licensing model, future plans and or a healthy community
and ubiquitousness are one of the major parameters to consider a UI
framework regardless of client or server side.
With latest evolution in Java some frameworks are more appropriate than
others in terms of ease of development and close knit AJAX capabilities.
--mustansar
On 07/30/2010 11:47 AM, Nate Angell wrote:
> I wonder if a common server-side UX platform is even really something
> useful to consider for Sakai 3. My understanding of Sakai 3 is that we
> are aiming for an entirely different model of development and
> distribution that makes the question moot.
>
> Capabilities for Sakai 3 are developed on the "backend" with results
> exposed as RESTful services that an entirely separate UX development
> on the "frontend" can present results from and interact with—in other
> words, a very clear separation of the logic and presentation layers.
>
> I'm imagining a future where the Sakai 3 officially distributed by the
> SF is mostly backend, along with a carefully crafted default UX for
> core capabilities. The team that works on this central release is
> already developing their own standards for UX development which I
> don't think includes a server-side UX platform.
>
> The rest (perhaps eventually bulk?) of Sakai 3 will be a way more wide
> open repository of contributed capabilities that talk to that core and
> add additional UX. In this arena, developers can use whatever UX
> technologies they can get to work—including GWT. If you want wide
> adoption of and additional developers working on your contributed
> capability, you'd do well to develop closely to core standards,
> including those that address cross-cutting concerns like usability,
> accessibility, localization, etc. If you don't care, use whatever you
> want, but don't expect anyone to notice or use your contribution.
>
> The advantage of this model is a more closely engineered core with an
> open contribution space where the technology diversity we decry in
> Sakai 2 becomes a positive thing, attracting more developers with
> different skillsets and demonstrating different technologies.
>
> Ideally, an additional distribution mechanism will be available that
> allows the SF or others to package Sakai 3 core with selected
> additional contributed capabilities, enabling "distributions" of Sakai
> 3 tailored for specific uses.
>
> There are other open source projects that use this model with
> substantial success.
>
> --
> Nate Angell
> Client Evangelist
> http://www.rsmart.com
> http://twitter.com/xolotl
> http://xolotl.org
>
>
> On Fri, Jul 30, 2010 at 8:45 AM, Chambers, Sara J
> <schamber at indiana.edu <mailto:schamber at indiana.edu>> wrote:
>
> Thanks for summarizing. I would like to broaden #5: There is
> significant interest in having a process to evaluate the pros and
> cons of various technologies and application architecture options.
>
> SJC
>
> Sara J. Chambers
> 812-855-7014 (office) 812-325-8151 (mobile)
>
>
> -----Original Message-----
> From: Michael Feldstein [mailto:michael.feldstein at oracle.com
> <mailto:michael.feldstein at oracle.com>]
> Sent: Friday, July 30, 2010 11:07 AM
> To: Michael S Elledge; markjnorton at earthlink.net
> <mailto:markjnorton at earthlink.net>
> Cc: sakai-dev at collab.sakaiproject.org
> <mailto:sakai-dev at collab.sakaiproject.org>; Chambers, Sara J
> Subject: RE: [Building Sakai] [Management] Gradebook Situation
>
> So far, here's what I'm hearing on this thread:
>
> 1. Everybody seems to agree that some kind of standards would be
> good, but not everybody agrees on the degree to which they are
> achievable.
>
> 2. There is a wide range of opinions on how important it is to
> have a "blessed" server-side UI framework for Sakai 3.
>
> 3. Of those people who believe a server-side UI framework is
> necessary, most of the preferences expressed so far have been for
> GWT, with one person raising Wicket as an alternative possibility.
>
> 4. The only specific concern expressed so far about having a
> server-side framework is its ability to support high and rising
> accessibility requirements.
>
> 5. There is significant interest in having a process to evaluate
> the pros and cons of various server-side frameworks.
>
> - m
>
>
> --
> Oracle
> Michael Feldstein | Principal Product Manager
> Phone: +1 8188172925 | Mobile: +1 9179218895
> Oracle Academic Enterprise Solutions
> 25 Christian Hill Road | Great Barrington, MA 01230
>
> Green Oracle Oracle is committed to developing practices and
> products that help protect the environment
>
> -----Original Message-----
> From: Michael S Elledge [mailto:elledge at msu.edu
> <mailto:elledge at msu.edu>]
> Sent: Friday, July 30, 2010 10:20 AM
> To: markjnorton at earthlink.net <mailto:markjnorton at earthlink.net>
> Cc: sakai-dev at collab.sakaiproject.org
> <mailto:sakai-dev at collab.sakaiproject.org>; Chambers, Sara J
> Subject: Re: [Building Sakai] [Management] Gradebook Situation
>
> I have to agree with Mark and Eli here. From an accessibility
> standpoint, client-side presentation is IMHO the way to go. We
> have yet to see a server-side solution that hasn't posed
> significant accessibility issues. It may seem old-fashioned to say
> this, but properly formed HTML with presentation by CSS and
> implementation by JavaScript still works best with screen readers.
> The potential for satisfying UI experiences has become much
> greater now that there are ARIA specs to make AJAX meaningful to
> screenreaders.
>
> Another point to consider--Wcag 2.0 sets a much higher bar than
> Wcag 1.0, which will make accessible server-side solutions even
> more difficult to achieve. Let's not tempt fate by bringing
> another JSF- like "solution" to Sakai--no one has time to
> customize tools that claim to be accessible--or render quality
> code--but do not.
>
> Mike
>
> On Jul 30, 2010, at 9:00 AM, Mark Norton
> <markjnorton at earthlink.net <mailto:markjnorton at earthlink.net>>
> wrote:
>
> > Attempts were made on two separate occasions in the past to create
> > technology standards for the Sakai community. Mara Hancock and I
> > chaired one of those committees for a year each. While a lot of
> work
> > was done to define tool standards, the community as a whole
> expressed
> > vast disinterest in either ratifying or adopting them. When it
> became
> > clear that the Sakai community really didn't care about standards, I
> > disbanded the committee.
> >
> >> The contributing community is too finite to further divide
> > contributors by multiple tools at the same level in the
> architecture.
> >
> > While I understand the point you are trying to make, the opposite is
> > also true. If you eliminate favored approaches to development,
> > especially UI technology, you will lose valuable contributors to the
> > Sakai community. For example, if a guiding technology committee
> > decided to standardize Sakai on JSF at this point, I suspect you'd
> > lose half the developers, me included.
> >
> > To some extend, new standards are emerging out of the Sakai 3
> > development effort. Ian Boston has expressed clear preferences for
> > certain approaches for Nakamura (next generation kernel). That is a
> > far more effective way to get Sakai standards. Not all agree with
> > Ian's choices and that's ok in large part because the reasons for
> > technology selection are well articulated and reasoned. It is no
> > longer a matter of personal preference (which is what Sakai 2
> devolved
> > into). It is a choice to contribute ... or not.
> >
> > - Mark Norton
> >
> >
> > On 7/29/2010 3:28 PM, Chambers, Sara J wrote:
> >> I agree that we should have one sever side ui framework and one for
> >> the client side. More importantly one standard toolset
> covering the
> >> entire application architecture (obviously S2 amd S3 will have
> >> differences). Seems we should articulate the pros and cons of each
> >> option and pull together a technical committee to make the
> selection.
> >> Actually IU would like to see a tech committee established to
> vet all
> >> technology decisions for Sakai and especially for S3 since
> that's our
> >> future. The contributing community is too finite to further divide
> >> contributors by multiple tools at the same level in the
> architecture.
> >> I'm personally not opposed to client side and server side UI
> dev but
> >> believe we should have one agreed upon toolset for each. IU is
> not a
> >> GWT shop but if the Sakai technology committee decided that was
> going
> >> to be the standard tool going forward for example, then we
> would come
> >> up to speed on it. What we don't want to do is support multiple
> >> tools at each level and/or
> > be locked out of making local customizations because a tool or
> service
> > was developed in a "non-standard" toolset. Just my .02
> >>
> >> Sara
> >> --------------------------
> >> Sent from my BlackBerry Wireless Device
> >>
> >>
> >> ----- Original Message -----
> >> From: Michael Feldstein [mailto:michael.feldstein at oracle.com
> <mailto:michael.feldstein at oracle.com>]
> >> Sent: Thursday, July 29, 2010 01:48 PM
> >> To: markjnorton at earthlink.net
> <mailto:markjnorton at earthlink.net><markjnorton at earthlink.net
> <mailto:markjnorton at earthlink.net>>
> >> Cc: Managers<management at collab.sakaiproject.org
> <mailto:management at collab.sakaiproject.org>>;
> >> sakai2-tcc<sakai2-tcc at collab.sakaiproject.org
> <mailto:sakai2-tcc at collab.sakaiproject.org>
> >> >; Sakai Developers<sakai-dev at collab.sakaiproject.org
> <mailto:sakai-dev at collab.sakaiproject.org>>
> >> Subject: Re: [Management] [Building Sakai] Gradebook Situation
> >>
> >> Not for the principle UI framework, but for the principle *server-
> >> side* UI framework. Many of the participating Sakai 3 schools are
> >> moving toward client-side development, but not all. Of those
> that are
> >> not, the server-side framework I hear mentioned the most is GWT
> these
> >> days. I have no strong opinion (and certainly no expert
> >> opinion) on which server-side framework would be best, but just
> from
> >> a skillset management perspective, I think we do need to make
> >> allowances for shops that don't have strong client-side development
> >> skills to be able to contribute.
> >>
> >> - m
> >>
> >>
> >
> >
> >
> >
> >
> >
> > =======
> > Email scanned by PC Tools - No viruses or spyware found.
> > (Email Guard: 7.0.0.18, Virus/Spyware Database: 6.15550)
> > http://www.pctools.com/ =======
> > _______________________________________________
> > sakai-dev mailing list
> > sakai-dev at collab.sakaiproject.org
> <mailto:sakai-dev at collab.sakaiproject.org>
> > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> >
> > TO UNSUBSCRIBE: send email to
> > sakai-dev-unsubscribe at collab.sakaiproject.org
> <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org>
> > with a subject of "unsubscribe"
> >
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> <mailto:sakai-dev at collab.sakaiproject.org>
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org
> <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a
> subject of "unsubscribe"
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> <mailto:sakai-dev at collab.sakaiproject.org>
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org
> <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a
> subject of "unsubscribe"
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
--
Mustansar Mehmood
Educational System Developer& Integrator
Information Technology
6100 Main St. MS 119
Houston Texas 77005
Phone:(713)348-2523
Fax :(713)348 6099
email:mustansar at rice.edu
I have yet to see any problem, however complicated, which, when,you looked at it in the right way, did not become still more complicated.
-- Poul Anderson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100730/3639f3b4/attachment.html
More information about the sakai-dev
mailing list