[Building Sakai] [Using Sakai] Support for additional browsers

Wed Mar 30 14:38:50 PDT 2011

I think all we can say is that at Umich:

In March of 2009 (we were on Sakai 2.5.3), ~15% of users were (attempting to
use the software) on a Webkit browser. In March 2010 (we were on Sakai
2.6.1), 35% were on Webkit. In March 2011 (we're on Sakai 2.7.1), 50% are on
Webkit. This number isn't going to go down and is still trending up.

Locally we have 2 people on the maintenance team, another actively involved
in frontend fixes and Noah Botimer. (Who instigates conversation, writes
long emails and provides great browser compatibility fixes) I can't speak to
the community priority, (maybe the BoF or others in this thread will) but
just point out that bugs related to browser compatibility in the past have
been "filed and looked at" rather than being "swept under the rug". I think
this is the policy even if it's not written down in stone somewhere. If
there is a specific problem that hasn't been, bump the priority and I'm sure
someone will look at it. ;)

I think it should go without saying that "Stay up-to-date on a more current
version of Sakai and you'll have better support with more generally
available browsers". The branch management process is tough, especially for
getting some stuff into old releases, and if nobody flags something they
want, it has no chance of getting back there.

This says nothing about what QA does though, but I think it's more about fix
priority, taking into account the severity of the problem. Obviously
something like inability to upload that you mention is a bigger problem than
text isn't aligned, but they should both be addressed. That's something we
locally fixed in the first 2.7.1 release of CTools, and the community really
does need a 2.7.2 release to pick up a number of issues.

Sometimes however (like with iOS not having support for contenteditable [for
wysiwyg] or file upload yet) there are real browser limitations that are
impossible to work around.

-Matthew

On Wed, Mar 30, 2011 at 5:08 PM, Mathieu Plourde <mathieu at udel.edu> wrote:
>
> But until this community decides to officially support new browsers, people
> are going to ask themselves what Noah brings up ("report it in JIRA and
> we'll look at it" versus "well, that's not really supported, but you can
> report it and hope"), which leads to sweeping the non-FF/non-IE issues under
> the rug.
>
> Would make an awesome BoF in LA, don't you think?
>
> [1] https://jira.sakaiproject.org/browse/SAK-19561
>
>
> =================================
>
> Mathieu Plourde, MBA
> Project Leader, LMS/Instructional Designer
> IT-Client Support & Services
> mathieu at udel.edu
> Office: 302-831-4060
>
> =================================
>
> TOP LINKS:
>
> Technology Troubleshooting: http://www.udel.edu/help
> Sakai at UD Support and Training: http://www.udel.edu/sakai/training
>
> =================================
>
>
> On Wed, Mar 30, 2011 at 4:48 PM, Noah Botimer <botimer at umich.edu> wrote:
>
>> Since I suspect that I instigated some of this thread, let me clarify my
>> position on it.
>>
>> I agree with both of these perspectives, effectively. My call is for
>> awareness and a reevaluation of our "supported set", which implies where we
>> do our testing and to what we tend to say "report it in JIRA and we'll look
>> at it" versus "well, that's not really supported, but you can report it and
>> hope".
>>
>> Personally, I don't think that stated and actual WebKit support is
>> optional anymore. And, truthfully, we're not too far away, but it's by way
>> of users and developers on the side -- not an outcome driven by a conscious
>> QA plan.
>>
>> I would tend to say that, even though the 2.8 QA has not officially been
>> targeting Safari, Chrome, IE9, or FF4, we should make a concerted effort to
>> at least record the issues and try to rally fixers and testers (and make it
>> official for 2.9). I can also say, from a development perspective, that
>> applying fixes to multiple releases (branches) is a tolerable load, but
>> setting up all of the instances and test conditions sometimes makes it
>> unbearable. Reports with an articulated willingness to test (under which
>> conditions) would be helpful.
>>
>> I recognize that this does constitute a marginal increase in development
>> resource demand and, possibly, a significant one for QA. The reason I urged
>> this conversation to happen on list is to understand whether the needs and
>> resources are aligned and, if not, have a community discussion of possible
>> paths forward. If, e.g., first-class Safari support is a top priority for a
>> number of partner institutions, the need becomes easier to recognize and
>> plans easier to operationalize.
>>
>> Thanks,
>> -Noah
>>
>> On Mar 30, 2011, at 3:42 PM, Matthew Jones wrote:
>>
>> This issue seems to come up every few months and I'm not sure what the
>> real problem is. I guess it depends on what you defined "supported" as being
>> and how up-to-date you stay with Sakai.
>>
>> If there is an issue with any browser (IE9/Safari/Chrome) and it's
>> reported in jira, from what I can see it gets fixed reasonably fast. What
>> specific issues are you having? Are you filing jiras for them?
>>
>> Just a quick search shows that many specific Chrome/Safari issues were
>> reported and fixed recently:
>>
>> * SAK-20129 - Chrome specific rendering of options misses radiobox for
>> Default setting - Assignments
>> * SAK-19561  -When uploading a files to Resources in Safari, 'Upload Files
>> Now' button is disabled
>> * SAK-15797 - Worksite setup table borders break on hover / invisible in
>> Safari
>>
>> Even IE9 has been tested and many things are currently being worked on,
>> likely not until 2.8.1, but there is the temporary emulation fix.
>>
>> I guess the biggest problem with this is if you don't upgrade Sakai often
>> (staying at most 1 major release behind), browsers will keep moving forward
>> and you'll be stuck on a release with incompatibilities. For instance 2.7 is
>> "significantly" better on mobile devices [1] and chrome/safari than 2.6 was
>> , and 2.8 and 2.9 will work even better. (Especially if those IU REST feeds
>> get in) There just aren't the (people) resources available to keep 2-3 year
>> old releases of Sakai up-to-date. Also, many browsers unfortunately don't
>> support an "Emulate old version" feature like IE9 does that we were able to
>> patch in with KNL-697.
>>
>> Personally I work and do most browsing in the (latest greatest) Chrome.
>> Many of the developers around me are using Safari. We use various features
>> of Sakai daily and often hear when somethings wrong and file/fix it, but are
>> on a reasonably newer of Sakai (2.7.1). I guess it's all a problem of
>> limited QA as you said (though the users are also QA) and what you locally
>> need to support. Locally at Umich I'd say emphatically that we don't need to
>> support IE6 or IE7 anymore but we do have to "support" Chrome & Safari
>> because the faculty and students aren't going to stop using it. And based on
>> the recent numbers they are using it as it these 2 webkit based browsers
>> combine for nearly 50% of all usage.
>>
>> [1] https://jira.sakaiproject.org/browse/SAK/component/11220
>>
>> On Wed, Mar 30, 2011 at 2:59 PM, Mathieu Plourde <mathieu at udel.edu>wrote:
>>
>>> Dear fellow Sakaigers,
>>>
>>> The use of Mac computers on our campus has grown dramatically over the
>>> last few years, and as a result many faculty and students would like to be
>>> able to use the Safari browser when using Sakai. The popularity of all iOS
>>> devices which rely on Safari also makes a case for making Sakai compatible
>>> with Sakai. Many features do work successfully in Sakai on this browser, but
>>> unfortunately there are several instances where unexpected behavior can
>>> occur and so we are compelled to warn our users, and request that Safari not
>>> be used with Sakai.
>>>
>>> Similarly, Chrome has recently been rated as the third most used browser
>>> behind Internet Explorer and Firefox. Since Chrome, Safari, and many mobile
>>> device browsers are based on the Webkit engine, once we make one of them
>>> compliant, we may find that it is relatively easy to make Sakai work with
>>> others. [1]
>>>
>>> This is not the first time that such a call to action has circulated
>>> on-list, but we believe that it is time to rethink our Firefox-centric
>>> approach, not only for Sakai OAE, but for the 2.x branches as well.
>>>
>>> Any thoughts or progress on these fronts?
>>>
>>> [1] http://gs.statcounter.com/#browser-na-monthly-201003-201103
>>>
>>> =================================
>>>
>>> Mathieu Plourde, MBA
>>> Project Leader, LMS/Instructional Designer
>>> IT-Client Support & Services
>>> mathieu at udel.edu
>>> Office: 302-831-4060
>>>
>>> =================================
>>>
>>> TOP LINKS:
>>>
>>> Technology Troubleshooting: http://www.udel.edu/help
>>> Sakai at UD Support and Training: http://www.udel.edu/sakai/training
>>>
>>> =================================
>>>
>>> _______________________________________________
>>> 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"
>>>
>>
>> _______________________________________________
>> sakai-user mailing list
>> sakai-user at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-user
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-user-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>>
>>
>>
>
> _______________________________________________
> sakai-user mailing list
> sakai-user at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-user
>
> TO UNSUBSCRIBE: send email to
> sakai-user-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110330/5bd135b9/attachment.html 