[Building Sakai] How to support proliferation of new tablets in CLE
Steve Swinsburg
steve.swinsburg at gmail.com
Sun Nov 4 15:36:20 PST 2012
Hi Keli,
I don't think anything is using that session param yet but I could see a check for that param and whether or not to render the CKEditor.
Also, the param is now is_mobile_device, the wireless one was incorporated into this. IIRC the wireless one was not being used by anything.
As for a list of user agents, that is what mobile-detect is meant to do. I haven't checked if the master list has been updated recently, to support more devices like the iPad mini. We can simply add more checks in there to setup different session params for different devices:
is_mobile_device
is_ck_editor_capable
for example.
cheers,
Steve
On 03/11/2012, at 8:58 AM, Keli Sato Amann <kamann at stanford.edu> wrote:
> Hi Steve and Matthew
> Thank you for your detailed responses; it's taken me a while to dig in, so I apologize for the delay.
>
> I appreciate Matthew's comment that the full site looks decent on a small tablet. So we may keep default 2.9 behavior that all tablets get the full site and wait for possible responsive design improvements. Otherwise, it sounds like we have the option of sending small tablet users to pda portal on our campus, but the onus would be on us to maintain a list of the user agents of all smaller devices, which would be quite a task on the Android side. At least users now have the choice to switch to mobile view and back, which is great.
>
> Steve, regarding your comments on CKEditor, I want to confirm my understanding of what 2.9 plan is
> A) is CKEditor controlled by default by "is_wireless_device" mentioned in SAK-22302, where it CKEditor is suppressed for ALL "wireless" (except for iOS5+, if that JIRA is addressed)?
> B) is your variable, 'is_mobile_device', primarily being used to control whether pda skin is going to be used, but also *could* be used to suppress CKEditor? (SAK-21334)
>
> That sounds like how it is intended to work when I read JIRAs and thread, but when I view QA site with iOS5+ and with Nook, I see CKEditor in both (CKEditor doesn't work on a Nook). So maybe CKEditor is not suppressed anywhere? or is it not "opt in" to get CKEditor, but opt out of getting CKeditor and Nook isn't on list?
>
> If that is the plan for 2.9 OOTB, we might also do this locally
> 1) enable CKEditor for Android3+
> 2) Using 'is_mobile_device', we might get devices that default to PDA skin, such as phone, to suppress CKEditor and use simple text (not sure if CKEditor would also disappear if switched to mobile view-- I don't think so, but I hope someone can confirm). However, I like Matthew's idea of eliminating most buttons from the CKEditor when it's on a smartphone or tablet, because it also saves space, but user never sees HTML if they are editing existing text. (one experiment I'd like to try if I can find phones--can Siri or Android be used to enter text via voice in a text field? in CKEditor?)
>
> If you think others would find it useful for rules for determining skin and editor to be described, you can edit A and B above as needed. Otherwise, I will pester my local developers to look at 2.9 to see how this is controlled and maybe write it up for the sakai user list. I'll need to describe how 2.9 works on mobile to our users and/or anticipate if we will need to do additional work.
>
> Best,
> User Experience Specialist
> Academic Computing Services, Stanford University
>
>
>
> ----- Original Message -----
> From: "Matthew Jones" <matthew at longsight.com>
> To: "Keli Sato Amann" <kamann at stanford.edu>
> Cc: sakai-dev at collab.sakaiproject.org
> Sent: Tuesday, October 30, 2012 7:03:39 PM
> Subject: Re: [Building Sakai] How to support proliferation of new tablets in CLE
>
> Just as a note, the only tablet I've tried recently, a Nexus 7 (smaller than the mentioned small iPad) works really well with the regular neoportal in 2.9. I wouldn't want it to go to PDA mode on any of these newer Android tablets. All functions and general navigation works well, including the CKEditor. The biggest problem is that some of the buttons (specifically on the editor) are small, requiring lots of zooming. Though for 2.10, we probably should be looking at eliminating most of the buttons and getting down to one row and a hidden optional row.
>
>
> Though most of these tablets still aren't super convenient for use in serious content creation. I also haven't tested all of the tools (like Samigo). Obviously a few functions (like audio questions) that either use flash or java applets which will never work on mobile. Those will have to be updated someday.
>
> I believe by the time next year rolls around, the majority of devices will support CKEditor, so detecting for that won't matter anymore, though users on a phone will get a better experience on the PDA portal still, not having to scroll and zoom as much.
>
>
>
> ----- Original Message -----
> From: "Steve Swinsburg" <steve.swinsburg at gmail.com>
> To: "Keli Sato Amann" <kamann at stanford.edu>
> Cc: sakai-dev at collab.sakaiproject.org
> Sent: Tuesday, October 30, 2012 5:40:24 PM
> Subject: Re: [Building Sakai] How to support proliferation of new tablets in CLE
>
> Hi Keli,
>
>
> https://jira.sakaiproject.org/browse/SAK-21334 is what you are after. The mobile detect library we are using (not the one you linked though), works via user agents. If the iPad Mini has a different user agent (and I am sure it would), it can be handled separately to the full size iPad.
>
>
> For 2.9, the device detection is in, and you can control tablets via:
>
>
> portal.tablets.use.mobile=true/false
>
>
> It defaults to false so that tablets are not taken to the PDA portal by default.
>
>
> WURFL, which is the previous library we used, was basically an enormous list of devices and their capabilities. Its licence changed so we had to switch. I am not aware of another library that has this information. Screensize and other capabilities could be reported via the browser, but perhaps some sort of responsive design for the entire portal would be better here.
>
>
> For disabling the CK editor, the portal sets up a session variable which tools can use to enable disable things such as the editor. I am not aware of any tool using it though.
>
>
> cheers,
> Steve
>
>
>
>
>
> On 31/10/2012, at 7:46 AM, Keli Sato Amann < kamann at stanford.edu > wrote:
>
>
> Hello
> Following up on an old thread, there are certain things I was hoping for with 2.9, but from my reading of the mobiledetect page ( http://code.google.com/p/php-mobile-detect/ ), it doesn't sound like we can actually detect the device attributes that would be necessary. So I'll describe what I wish we could do, then describe what it sounds like we may have to actually do. As a lay person, I'm doing my best to follow along in JIRA (SAK-22302 and related), but can those in the know describe what *actually* is going to happen for 2.9?
>
> 1) Direct users to PDA portal if screen size is 7.9 inch or smaller (iPad mini is the largest of the small tablets). However, it doesn't seem like mobileDetect can detect screensize though, only if something is a tablet versus a phone. So we would have to choose to direct all iPads to full site, or all iPads pda skin. Personally, I think we would opt to direct tablets to full site; at least 2.9 will make it easier for users swith smaller tablets to then switch to pda skin. But if we could build in some other way, other than size detection in the future to direct users to the proper skin (save preference, use some other detection method), or expand on our detection methods to include form factor detection, that would be ideal.
>
> 2) Suppress CKEditor when it won't work (browser doesn't support contenteditable OR when iOS5+ or Android3+) AND when screen size 7.9 inch or smaller. However, it doesn't seem like mobiledetect can detect contenteditable and even it it did, it doesn't accurately predict whether the browser actually supports CKEditor, per Matthew's note below. Sounds like OS version detection is in beta for mobile detect so we might have some luck there eventually, but without it, it sounds like we should to suppress CKEditor whenever ANY phone or tablet detected, unless there are some OS out there that have supported CKEditor from their first version. This is not currently happening on Qa server though --when I go to 2.9 with a Nook running a custom version of Android, my screen freezes when I touch the ckeditor.
>
> If at some point we do implement something like the form factor detection that Matthew mentions AND we could also detect version, we could target the right experience a little better. It is kind of a bummer that we're finally able to support CKEditor use on current smartphones, in theory but not in practice. But for now, simple text is probably better for new content creation on ALL touch screens anyway, since it's a little unwieldy to control cursor position in CKEditor to format text and the tool bar takes up precious space. The only drawback is when you are editing something that was originally created in rich text, it would be nice to see CKEditor instead, because otherwise you'll see html.
>
> Keli Amann
> User Experience Specialist
> Academic Computing Services, Stanford University
>
> ----- Original Message -----
> From: "Matthew Jones" < jonespm at umich.edu >
> To: sakai-dev at collab.sakaiproject.org
> Sent: Monday, January 9, 2012 6:32:54 AM
> Subject: [Building Sakai] How to support proliferation of new tablets in CLE
>
>
>
>
>
> Yea, this is a somewhat tough issue (contenteditable) because as this post says
>
> "This works great but for someone looking to get this going on iPhone/iPad: the contentEditable property IS defined. Trouble is the OS doesn't actually support " - http://stackoverflow.com/questions/1882205/how-do-i-detect-support-for-contenteditable-via-javascript
>
> So if you try to use feature detection (like Modernizr) then it will still succeed. And if you do device detection, then it works in iOS5 but fails in iOS4!
>
> Getting rid of WURFL as Steve suggested is a good idea though. Both because of licensing problems and because it just sits there taking up 100MB in the heap at all times.
>
> The good news is for your original question (1) is that the new mobile browsers (iOS 5+ and Android 3.0+) are finally supporting this specific feature for editing ( http://caniuse.com/contenteditable ). And as far as I've seen in usage reports and overall usage (at least at Michigan), tablets are still either lightly used or used as as secondary option when a notebook is also available. So there's still a year or two till they're everywhere. :)
>
> For the (2) part, Steve's solution will make changing the string easier and more legal than changing the WURFL, so that really should be done. I think that the more important thing for the medium term future will be combining feature detection with device/form factor detection ( https://github.com/PaulKinlan/formfactor ) to ensure the optimal user experience. You're realistically not going to want to present the same view to a mobile phone with a 10 cm diagonal as one with a 25 cm diagonal.
>
> It also seems like if the feature detection was available client side (like in one of these js libraries) disabling specific features in certain places (like forums) would be much easier.
> On Jan 9, 2012 1:56 AM, "David Horwitz" < david.horwitz at uct.ac.za > wrote:
>
>
> Just a point for people looking at making a feature
> available/unavailable it is far better to query the service (being WURFL
> or Mobile detect based) for capabilities rather than specific devices.
> Part of the fragility of the current use is that it ask "is this an
> iPhone" rather than "does this device support feature x".
>
> D
>
> On 01/09/2012 01:01 AM, Steve Swinsburg wrote:
>
>
> Hi Keli,
>
> The portal currently uses the WURFL library to detect mobile devices, however recent license changes means we cannot upgrade, so I am looking at switching it to an alternative project called Mobile Detect, which is based on MobileESP and available in the maven repositories. It is Apache2.
>
> https://jira.sakaiproject.org/browse/SAK-21334
>
> Once the code is cleaned up then tools will be able to check the mobile device easier, and via an entityprovider.
>
> cheers,
> Steve
>
>
> On 07/01/2012, at 11:42 AM, Keli Sato Amann wrote:
>
>
>
> Hello,
> We are running 2.6 locally, but we added the patch that suppresses the rich text entry of the fckeditor and replaces it with simple text entry that comes with 2.8. We have manually updated that patch to do this switch when it detects additional useragents (iphone, and now Android phones and iPad).
>
> I was hoping this also covered Android tablets, but we just tested it on a Nook and we still see the non-responsive rich text options. So we will have to manually update this to include the useragent for the Nook and I guess the Kindle Fire if we can find one to test.
>
> My questions are this:
> 1) Is the rich text entry of the ckeditor (which I think comes with 2.9) supported on iOS and Android devices or will we need to continue this workaround?
>
> 2) If we have to continue this workaround, is there a different string we can search on that isn't quite so specific that would cover all iOS and Android devices so we can stop updating this?
>
> 3) We created another dependency: in Forums, we hid the Delete and Setting options for Topics so that they only show during a hover. We want to completely hide these options on touch devices (while it is possible to get this to display with a double click, this is confusing). So now we need to do the useragent check in two locations. Is there a way to maintain the approved list in just one location?
>
> I may not understand any of your answers, so I'm cc'ing Lydia ;-)
>
> Thanks,
> Keli Amann
> User Experience Specialist
> Academic Computing Services
> _______________________________________________
> 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-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-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-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-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"
More information about the sakai-dev
mailing list