For me, one of my personal holy grails has been the elimination of all frames – another step has been taken in that direction and is now in the trunk of Sakai for you to use and play with. Over the past few weeks I have been working on changing the Sakai PDA portal to eliminate the *last* frame and blend the navigation of Sakai with the tool.
Here is a picture of frameless Sakai running on the PSP and some pictures of the portal running on my Treo.
http://www-personal.umich.edu/~csev/images/2007/04/DSC01054.JPG
http://www-personal.umich.edu/~csev/images/2007/04/DSC00039.JPG
http://www-personal.umich.edu/~csev/images/2007/04/DSC00041.JPG
http://www-personal.umich.edu/~csev/images/2007/04/DSC00043.JPG
I got a PSP for my son Brent yesterday for his birthday and he was quite unhappy as I immediately took it from him for several hours as I tested it out on the new Sakai frameless PDA portal. He will be even less happy if I tell him I need to take his brand-new PSP to the IMS Learning Impact meeting all next week so I can do demos. :)

The technical approach is pretty straightforward. Since the PDA portal only allows one tool on the screen at the same time, then entire portal page becomes a tool page with href based navigation interspersed in the tool output. The portal.css is not used at all in the PDA portal – the tool CSS owns the whole page with a little tiny CSS added for the navigation bits.
Technically, when the feature is turned on for a tool, when the portal is displaying a page with a tool on it – instead of emitting an iFrame – it actually dispatches a buffered request/response to the tool to get the tool markup. It then scans the markup extracting the body and head material and passing this up to the Velocity rendering (macros.vm and pda.vm) which assembles the final page interspersing the head and body material appropriately. The portal code and the Velocity code do this on a reques by request basis and if anything goes wrong with the markup parsing or buffering the portal drops back to using iframes.
Thanks to testing from David Horowitz and Stephen Marquad and debugging by Antranig, we have quite a few tools working. The only tools that do not work at this time are the chat tool (both old and new) and the old discussion tool and wiki – these seem to use iframes or pull data from tool urls – the problem is that the tool URL now contains navigation in addition to tool output so you see extra navigation’s. I have not tested *all* tools so folks will need to test. The only requirement is really simple – this is *not* XSLT – the HTML does not have to be perfectly well-formed. All that is necessary is a clearly identifiable head and body tags (both begin and end) that the parsing code can find. This would not have been possible without the portal refactoring work of Ian Boston and the JSR-168 work of David DeWolf – because JSR-168 was already buferring and wrapping requests – it was pretty easy for me to imitate that work and do a similar thing for non-portlet tools. So many deserve the credit for this.
Stephen and David H. came up with a very clever idea – in the place where we redirect to /portal – they are going to write a JSP that looks at which browser folks are using and redirects them to either /portal or /portal/pda. As an example, Blackberrys, Treos, and PSPs can be automatically sent to the PDA portal. But *EVEN MORE COOL* – JAWS can be sent to the PDA portal. We could ultimately make this part of Transformable/FLUID – where users set a preference for “less complex navigation” or some such and then folks get sent there because they want to be sent there.
This work is now complete and works at an “experimental” level in the trunk.
For folks who want to run production or test the new feature, the feature must be enabled on a tool by tool basis after testing. The default for this property is *COMPLETELY OFF* :)
portal.pda.experimental.iframesuppress=sakai.motd:sakai.iframe:…:sakai.synpotic.chat:
If you are bold/brave/foolish you can turn on for all tools – this version of the property is bad for production but plenty fun for testing.
portal.pda.experimental.iframesuppress=:all:debug:
I have a version of Sakai all checked out and running at the following URL
http://s-sakai-1.dmc.dc.umich.edu:8096/portal/pda
If you don’t want to type this nasty URL, I also made a shortcut page at www.dr-chuck.com/pda/. This is the dev sandbox server so it might be down. If the server gets rebooted my tomcats might not get restarted. But it is a nice place to play. I also have a version of IMS Tool Interoperability Tool and Tool Interoperability Portlet installed on this system as well as Zach’s latest IMS Common Cartridge stuff – so it might be a fun playground.
Of course there is still much to do. I want to have Mike and Colin take a look at the accessibility of the portal and if there are markup improvements that need to be done. I also want to get transformable into this portal – because this view will react REALLY well to Transformable as the whole screen will react and resize perfectly if we get it right.
There is a LOT of testing to be done – I have not tested every single tool – there is a neat debug property that can be set (see above) that logs the parsing of the buffered responses. If the portal sees a response that it cannot parse – it simply falls back to putting the tool in an iframe. So we might find a few tools that really mangle their head or body tags like adding spaces or new lines. The solution will either be to clean up the markup from the tool or teach the parser of the buffered response to be more tolerant.
Another general issue this new capability and the new browsers it brings will expose is “within tool” markup which is tending towards increasingly heavy use of Javascript. As we have pushed more and more features into tools and demanded increasingly slicker interfaces- we have been increasing the complexity of the Javascript in the tool’s output. The frameless portal cannot compensate for this. What it really means is that we will have a bunch of new non-compliant browsers (albeit small communities) complaining about feature X or Y working on the Treo browser or some other tiny browser. My hope is that we can focus on the more modern PDAs like the PSP and upcoming iPhone – but I do think that we need to keep things a bit simple as we embark on”improving usability” – for many users and for many browsers – “more usable” is often related to”more simple”. The nice thing is that for accessible users and other transformable users – the frames are gone and they are using modern speech-enhanced browsers – so they will see improved benefit across a wider range of our existing tools than things like a Treo.
This was too late to make 2.4 even as provisional – we can probably put it into a 2-4-x maintenance branch because it is not user visible without the property being set – it is just a few commits in the portal directory – the commits are simple and pretty safe and not likely to harm the normal portal or operation with the property turned off. It will not make it into a 2.4.1, .2, etc release – but I assume many sites who are concerned about accessibility and support for PDAs – and hey it might even work with IE7 since the portal CSS is extremely simple.
Since a lot of schools are planning on running 2.3 in production this fall, I am planning to back-port the entire 2.4 portal including these capabilities to 2.3 so folks can make use of these features without being forced to go to 2.4 just to gain support for PDAs and improved accessibility. This will also bring JSR-168 support to Sakai 2.3. I expect to do this ins a branch (not the 2-3-x branch) and make it so that folks can check out a complete replacement for the portal code in 2.3 from this back-port branch. The 2-3-x branch needs to continue to maintain the 2.3 Charon (non-velocity) portal. This also will not appear in a formal Sakai Foundation 2.3.n release.
At this point, I am kind of “done” to the level I can go with this (other than the back-port to 2.3) – it works and passes my dev-tests. So if people find this interesting and important – you should test it, debug it, fix it and use it and give me feedback. If no one tries this stuff – it won’t get any better (even though in my considered opinion it is already VERY VERY cool right now).
Now that this is done – I can start working on taxes this weekend. :)
Again – thanks to Stephen, David, Ian, and Antranig for all the help on this.