> On Fri, Jul 20, 2012 at 09:54:34AM -0700, Nate Angell wrote: >> Thanks for the link Clay. >> Reading that description of SPA raised two questions for me, >> about the >> relative priorities of a couple of issues that may arise out of a >> move to >> SPA: >> 1) The back button: I'm assuming that our move to SPA is >> motivated by a >> desire to deliver increased usability. Sakai CLE has long >> suffered from >> inconsistent behavior with browser back buttons. While it would be >> convenient to have Sakai itself handle all navigation, users are >> pretty >> well trained to use back buttons to get to previous states. Are we >> thinking to try to support back button navigation in SPA from the >> start? > > We already handle this pretty well. Note that the message inbox > screen is > single page (opening a message doesn't do a page load, it just gets > the > message through ajax and puts it in the page while hiding the message > list), but the back button functions as you'd expect.
That's correct. In fact, for the SPA we are planning to go one step further and use the HTML5 Histroy (pushState) API, which will give us more readable URLs than the current ones. E.g. http://.../content#p=<id>/FileTitle can be rewritten to http://.../content/<id>/FileTitle >> 2) Search-engine discovery of public content: I understand that >> we have a >> goal to support search engine discovery, which makes sense in an >> application designed to share content publicly, but still have >> some work >> to do there. Are we thinking to build in better discovery in the >> move to >> SPA, or would that be a later goal? > > This is already a problem, but going to single page shouldn't make > solving it any more difficult than it already is. This is because the > reason it's a problem already is that we're already doing single > page type > stuff (see comments about inbox above). I can't really speak to the > timeframe for fixing it though. The solution for this is unrelated to the introduction of the SPA. However, it is something that I'd like us to introduce as soon as possible, and the pending merge for generating PDFs and thumbnail images from Sakai Docs will put the foundations in place for this to happen. The solution is described at [1]. [1] https://developers.google.com/webmasters/ajax-crawling/docs/getting-started Hope that helps, Nicolaas >> = nate >> >> On Fri, Jul 20, 2012 at 5:36 AM, Clay Fenlason >> <[1][email protected]> wrote: >> >> FYI, if you're like me and were unfamiliar with this coinage, >> "Single >> Page Application" is a real thing: >> [2]http://en.wikipedia.org/wiki/Single-page_application >> ~Clay >> On Fri, Jul 20, 2012 at 8:13 AM, Nicolaas Matthijs >> <[3][email protected]> wrote: >>> Hi everyone, >>> >>> I wanted to reach out to the list to give an overview of the UI >>> priorities that will be worked on during the next sprint. >>> >>> In general, there will be 1 clear priority, which is around the >>> consolidation of the UI as per designs that have been presented to >>> the >>> URG, transforming it into a single page app and consolidating >>> existing >>> features, hopefully in many places introducing consolidated APIs. >>> >>> Other than that, a few things will be happening on the side as well: >>> >>> - 1.4.1 tag or release that will do a full clean-up of all places in >>> the code that don't comply with the style guide. A commit hook >>> enforcing compliance will be introduced as well. >>> - review of widgets that have been submitted to the Widget Library >>> (4 >>> pending) >>> - creation of screencasts and some updates to the Widget SDK >>> >>> In terms of existing JIRA tickets, we will go through the ticket >>> list >>> and change the status of all 1.5.0 and post-1.5.0 tickets that >>> will no >>> longer be relevant after the consolidated UI is in place to >>> "Blocked" >>> and will assign it to a new component. Once the changes have been >>> made, we can go through them and resolve them if the issue is no >>> longer relevant or has been fixed. >>> >>> Hope that helps, >>> Nicolaas >>> _______________________________________________ >>> oae-dev mailing list >>> [4][email protected] >>> [5]http://collab.sakaiproject.org/mailman/listinfo/oae-dev >> _______________________________________________ >> oae-dev mailing list >> [6][email protected] >> [7]http://collab.sakaiproject.org/mailman/listinfo/oae-dev >> >> References >> >> Visible links >> 1. mailto:[email protected] >> 2. http://en.wikipedia.org/wiki/Single-page_application >> 3. mailto:[email protected] >> 4. mailto:[email protected] >> 5. http://collab.sakaiproject.org/mailman/listinfo/oae-dev >> 6. mailto:[email protected] >> 7. http://collab.sakaiproject.org/mailman/listinfo/oae-dev > >> _______________________________________________ >> oae-dev mailing list >> [email protected] >> http://collab.sakaiproject.org/mailman/listinfo/oae-dev > > > -- > D. Stuart Freeman > Georgia Institute of Technology > _______________________________________________ > oae-dev mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-dev _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
