Versions Compared

Old Version 2

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Meeting minutes for

...

September 8, 2008

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

Sakai/OSP 2.4/2.5

No new issues

Sakai/OSP 2.6 and beyond Development Status

...

  • SAK-14279 Avoid wasteful calls to resolveUuid
  • SAK-14280 Improve efficiency of form handling by caching schemas
  • SAK-14165 Portfolio assembly is slow with many completed Forms
  • SAK-13146 Add custom form as an option on main page of wizard
  • SAK-13719 (IUPUI) Matrix tool / tracking permission changes
  • SAK-14417 Improving the Portfolio User Experience
  • OSP Design and Development
  • 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.). There were no objections. This is in trunk.
  • 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.. No objections. This is in trunk.
  • 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.There are patches attached to the ticket, but they are not going into 2.6. UM will be running the patches in production.
  • SAK-13146 Add custom form as an option on main page of wizard. This is 3/4s done and will be finished for 2.6Chuck Hedrick wasn't on call to discuss his progress.
  • 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 BreukerIU will be going live with this next week. Lynn will do a demo sometime afterwards.
  • SAK-13725 patch to enable exposed matrix and exposed wizard in OSP. You canThis isn't just enable it -- there are other bugs that have to be fixed first. Beth has a comment to that effectready for production, so it will not be in 2.6.
  • SAK-14417 Redesign Portfolio User Experience. Beth created this ticket as a place for tracking plans for the Portfolio Tool redesign. It links to Nathan's mockups and also to a page for adding requirements.

New Development for 2.6

We reviewed most of the new screenshots of the proposed Portfolios tool UI rework by Nathan Pearson

...

. 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.1: The "Options" column should probably be renamed "Actions"
  • 1.1a: Perhaps making the portfolio active or inactive should be an option in the pop-up menu. Under comments, it would be nice to have some way of indicating that unread comments have been added.
  • 1: Approved
  • 2: The question arose whether anyone has large numbers of portfolio templates, which would make this screen unwieldy. Probably not.
  • 3: Comments included:
    • Does the screen take up too much room once you put the Sakai navigation in?
    • Is the progress indicator misleading, since it would say "Complete" before you are finished with, say, adding all the pages you want. Perhaps it would be better to say "Ready" rather than "Complete".
    • Should the Status section be moved to the Sharing page? This would take up less real estate on this page, but would make the Sharing screen more cluttered.
    • Nathan explained that it is generally a good principle of UX design to allow multiple ways of accomplishing the same important task, which is why he put in tabs as well as links for actions such as "Add/Edit Content".
  • 3a: The question arose of when the Preview button should become available. Nathan thought it should always be there, but show a blank screen with a message like, "No portfolio is ready for previewing".
  • 3b:
  • 4: Jan expressed concern that some of the efficiency of the current screen is lost here. For example, the user can't tell how many schools they've added to their resume. Having to click back in to each section would be tedious. Nathan said that he believes we have more of a need for ease of learning than efficiency. It would be possible, however, to indicate how many items of a particular type have been added.
  • 5: Since the display name is just for saving the Outline Options form, it would be best just to use script so that it isn't displayed at all. The Presentation Name is from a UM Outline Options form. This screen prompted the question, where do you name the portfolio (the name that will show up in the list of portfolios). It was explained that the portfolio name that has been displayed throughout the screens (Nathan's Resume Portfolio 1) has an edit link next to it to allow the name to be edited. (It remains unclear to the author of these notes when and how the user would be prompted to name the portfolio in the first place.)
  • 6:
  • 6a:
  • 6b: There should be a select all button and that button should select all users, not just the ones listed on the first page. Are groups necessary? Yes.
  • 6c1:
  • 6c:
  • 6d: