[Building Sakai] [Management] Gradebook Situation

[Michael S Elledge]

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>  
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]
>> Sent: Thursday, July 29, 2010 01:48 PM
>> To: markjnorton at earthlink.net<markjnorton at earthlink.net>
>> Cc: Managers<management at collab.sakaiproject.org>; sakai2-tcc<sakai2-tcc at collab.sakaiproject.org 
>> >; Sakai Developers<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
> 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"
>