Page Comparison

...

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

...

1. 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.
2. 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.
3. 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.
4. 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.

1.