Page Comparison

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 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.

1. 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 appear see on this 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
2. 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'
     
3. 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?

3) Exceptional mobile functionality

...

1.