2008-09-08 Conference Call

Meeting minutes for August 25, 2008

Note that due to Labor Day, next week's meeting will be held Tuesday, Sept. 2 at the normal time.

No new issues

Noah added two new efficiency-related issues: 14279 and 14280.

SAK-14279 Avoid wasteful calls to resolveUuid. The UUID is now looked up only once, not twice. Should this be merged with 2.5? (UM will be merging it into production this week and will let the community know how it goes.)

SAK-14280 Improve efficiency of form handling by caching schemas. When working with multiple instances of the same form type, the schema is retrieved and deserialized for each form. The StructuredArtifactHome can be cached to avoid the expensive cycles. Since schemas are rarely changed and only through administrative action, they can likely be cached indefinitely. At the least, caching at the thread level helps significantly.

SAK-14165 Portfolio assembly is slow with many completed Forms. Noah is working on a change to make looking up forms more efficient. Charles Hedrick thinks it makes more sense, both functionally and for efficiency, to only search the user's worksite for forms. Noah will implement change so that by default the behavior is the same (look everywhere for forms), but it will be done more efficiently. Then we can think about Charles Hedrick's approach.

SAK-14214 list of users to share can get impractically long; optionally limit users. Charles Hedrick finished this. It allows sites to limit the number of users displayed in the share list if the site has too many users. The limitation is done by role, so that you can list faculty members but not the students. This is controlled by a sakai.properties setting.

SAK-13146 Add custom form as an option on main page of wizard. This is 3/4s done and will be finished for 2.6.

SAK-13719 Matrix tool / tracking permission changes (IU). These changes have only been made to the matrix, not the wizard. This will have to be taken into account when the community decides whether or not to merge the IU branch into trunk. Sean agreed to update the Jira with a screenshot and comments made by Mark Breuker.

SAK-13725 patch to enable exposed matrix and exposed wizard in OSP. You can't just enable it -- there are other bugs that have to be fixed first. Beth has a comment to that effect.

We reviewed the screenshots of the proposed Portfolios tool UI rework by Nathan Pearson. Nathan joined the call as the meeting was supposed to end, but a small group went back through the entire set of screenshots with him. Comments included:

Screen 1.After: We would like to see a mockup of how the screen would look in the case where many portfolios have already been shared with the user. That is a situation in which it is useful to be able to hide some of the portfolios in the list. Also, since there is not always a portfolio outline form, the number of steps is not set. Would it be better to have a TurboTax-like breadcrumb trail at the top that users can click on to go from step to step. How easy would it be technically to have contextual information about the steps? Nathan liked the breadcrumb idea, and pointed out that that moves us towards the "hub" UI model, where you have a central page from which you go off to perform tasks, then come back to the central page. Nathan will mock up a hub interface so we can see what it would be like.

Screen 2.After: It must be possible to select free-form portfolios. Also, it is often the case that there is only one portfolio template available for a site. Is this page even necessary if there is only one? Can't the single template just be assumed to be the user's selection?

Screen 5.After: The original screen had two advantages. One is that the user can see what forms have already been selected, so you don't lose track of what you've already done. Second, selection of multiple pages in the multi-select box is straightforward, if not particularly elegant. UM, for example, has sites where users regularly add 10 forms of the same type. Lynn suggested that multi-select could be handled with checkboxes. Nathan responded that we are weighing efficiency against learnability, and it may be that learnability is a more important consideration in a screen that is not used that often.

Screen 5a.After: Having "<add new>" as an option in the dropdown is a little too subtle - everyone but Lynn missed it. Should it be a button?

Screen 5b.After: Everyone liked the preview of the form, though it was recognized that few forms will be as easy to preview as the resume entry shown in the wireframe.

Screen 6: The difficulty with multiple "titles" was discussed, as this screen attempts to reduce to one the three types of title (portfolio name for listing, options form display name, and portfolio title as used in the portfolio website). The options form display name can probably be eliminated by accepting the automatically generated name but not displaying it in the form. There seems to be a legitimate need for the other two titles, though maybe a change in nomenclature would help. The idea of getting rid of the description field was discussed, since people don't seem to use it. Apparently it is available for display using a display triangle when a portfolio is shared with someone, so maybe it is useful after all.

Screen 7.After: The share page would have multiple options, and a hidden div would slide down in cases where more info is needed, such as who you want to share with. Nathan will finish those mockups this week.