Page Summary: Requirements for "Sakai Mobile" broken down on level of perceived level of importance & (my estimated) likelihood of implementation. Based on Quality function deployment methods.
"Mobile Support" for Sakai is a huge area that everyone wants. I believe we should mostly limit this discussion for "Mobile Support" to be specific to smartphone devices with Web Browsers that have some support for html5 and javascript. This includes or will include Android, iPhone/iPod, BlackBerry 6. This market will continue to grow, and the support for any older devices will always be very minimal.
Please add/edit this page as desired. Consider this a draft.
1) Normal mobile functionality
These are items that either exist now, are being worked on, or require are minimal effort.
- QA/Fix issues with the PDA portal, at least on Android/iPhone.
- WYSIWYG should be disabled for Mobile Devices (SAK-18098) - Because currently iPod/iPhone in particular don't support flash or contentEditable, most of the high profile editors won't work. [1] It should just be disabled.
- This doesn't work on Android either, making adding content in most areas impossible
- PDA portal should auto detect and redirect (SAK-18720)
- Perhaps a user preference might be optioned to toggle this behavior (Mobile Device options?)
- The most used tools should all be able to be submitted to and transferred from
- Based on an analysis done at BYU [2] the most highly used tools are
- Resources(85.9%), Gradebook (78.0%), Announcements (68.9%), Email (68.1%), Test and Quizzes (30.1%), Forums (13.5%)
- I believe most Sakai sites would be the same. Maybe Wiki would be as high as forums?
- We also really don't have internal mail, opting mostly to store mail outside the LMS (except for Forums/Email Archive)
- It's possible downloading certain types of content from resources wouldn't do anything. Also, I'm not sure if all devices could upload to resources.
- Based on an analysis done at BYU [2] the most highly used tools are
Other issues, such as the login portal not appearing correct (SAK-18768) and some other stying issues are also being worked on. Each tool may also have some styling issues to get to fit correctly. Overall I would say that the Normal functionality was "good" if PDA portal was the default and WYSIWYG went away.
2) Expected mobile functionality
These are items that are a little more effort but most people want them to work
Some of these were gathered by Daphne in SAK-11568. Some of them are new ideas.
Even after the "PDA portal" version of Sakai works, it doesn't work like users expect a mobile application to work. It also doesn't have the end points for building stand-alone mobile apps.
- The "Home screen" for most mobile apps (Twitter/Facebook) is essentially a time based view of everything that's new for that individual. The main view for Sakai on the web and on the mobile device essentially forces you to "find out for yourself" what's new. (Though a few "My workspace" synoptic tools do aggregate across all sites)
- New items on the wall, New notifications, New friends, New mentions
- Mobile Sakai needs to have a "Home Page" with a "What's New" style feed showing all of the newest items
- This could either be implemented by writing entitybroker feeds for the most highly used tools mentioned in (1)
- Most access to tools via rest (or entitybroker) feeds are on the proposed list of features for 2.8 and would make a number of things easier
- This could also possibly be implemented by hooking into the notification system and capturing all notifications (even those set to none), as this seems to be the most useful data someone would want to see on a feed anyway.
- The performance impact of this would need to be examined
- Even if a notification email is not sent, it could appear on this page
- This could either be implemented by writing entitybroker feeds for the most highly used tools mentioned in (1)
- There should be some type of WYSIWYG editor on the text areas
- Wordpress recently rolled out some type of WYSIWYG for their mobile site. [3] Perhaps this is more of a 'wait and see' than implement, but either way the mobile WYSIWYG will have to have much less buttons than the full blown one because of screen 'real estate'
- Wordpress recently rolled out some type of WYSIWYG for their mobile site. [3] Perhaps this is more of a 'wait and see' than implement, but either way the mobile WYSIWYG will have to have much less buttons than the full blown one because of screen 'real estate'
- Some type of single sign-on authentication will probably need to be provided/suggested so that (stand alone) mobile apps (if developed) won't be asking for usernames passwords.
- Either a shared signon with a big OpenId provider or our own.
- The Mobile team at Michigan is supposed to be implementing something for their single sign-on on top of cosign, but this is currently still unreleased. [4]
- Perhaps just requiring the mobile phone number and detecting that is sufficient?
- Either a shared signon with a big OpenId provider or our own.
3) Exceptional mobile functionality
These are items that would be great to have but mostly dreams and this point. Theyt might work in 'some' web site now (gmail), or are available in a coming spec (html5)
These items are pretty unlikely for Sakai 2 without a large effort (GSoC or significant FTE committed)
Fill this in more later.
- Being able to take the browser offline. Using HTML5 Web Storage to locally cache data. Similar to what many mobile apps do (like GMail). Then you don't have to maintain a persistent data connection. Problems with invalidation and new data. Would probably require entitybroker feeds to exist and UI's to be rewritten in javascript.
- A working back button.
- On both Android and iPhone the back button is even more important than the browser. It bacically undoes whatever the last action was, whether that is removing a dialog box, going back to the last screen. Incorporating consistant back button behavior into mobile navigation would be great.
- Supported integration for conferencing/chat tools, link them up to classrooms.
- It seems ilke big blue button is getting the most support, it would be great to be able to switch to that and use it. This is quite a ways down the road though because of the lack of Flash on iPhone/iPod, and the HTML5 spec support for cameras being a little ways off.
- Push notification to phones.
- Android (and I believe iPhone) support pushing notifications to the phones rather than polling.
- In Android 2.2 (mostly unreleased) it's by a "Cloud to Device" messaging API that seems really nice. [5]
- This seems like something we'd really like to take advantage of. Facebook/Twitter/Gmail and others all push notifications and I'm addicted.
- For example, notification on a new announcements in any course, or a new file uploaded. Perhaps configure how you want mobile push notifications as well.
- This might be something more to think about for Sakai 3. I think this will be even more important in 3-5 years.
- Android (and I believe iPhone) support pushing notifications to the phones rather than polling.
1. http://cksource.com/forums/viewtopic.php?f=6&t=18317
2. http://www.slideshare.net/jonmott/eli-2010-the-genius-of-and-the-cms-the-oln-2958774 (Slide 11)
3. http://www.blogherald.com/2010/07/07/wordpress-ignores-iphone-updates-android-app/
4. http://mobileapps.its.umich.edu/mobile-apps
5. http://android-developers.blogspot.com/2010/05/android-cloud-to-device-messaging.html