Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

  • The portal isn't going away, rather we keep finding more and more things we want them to be able to do.  Users want to be able to consume that information outside of the portal framework too however.
    • Texting
    • Facebook
    • Email
    • They dig for it (look for it in the portal)
  • Portals are a place of aggregation for user information - it pulls stuff together from multiple systems and sources.  It should be personalized information tailored to the user, not just a list of links.
    • We can present a customized list of links based on user roles, preferences, etc. to enhance their experience.
  • Should be at least minimally customizable by the end-users to make it as useful as possible.
    • The extent of the customizations depends on the provider's vision for the portal
    • There should be research done as to the extent of this functionality however, as many users don't do customizations or really even want that functionality - just give me what I need to do what I need to do.
  • The ability to do intelligent information provisioning - offer suggestions as to similar classes, what other people have done who have similar preferences, etc. - the "Netflix" model.
    • Need to balance this functionality for performance reasons
    • Are we trying to compete with Facebook?
      • Eg. stream of events and information, etc.
  • Provide users the ability to have a "favorites" part in their portal - most used portlets, ability to save personal url's, etc.
  • Intelligence and tracking of app usage - things used most often float to the top, things not used float to the bottom.
    • Be able to control float during specific times (registration links at the end of the semester, etc.)
    • Can make it more difficult for user training/less technical users since things move around all the time.
      • Search box to bring up specific apps directly based on metadata stored for each portlet?
    • Have URLs that are reusable/deep-linkable (can link directly to a portlet)
      • easily-spelled links
  • Tabs versus tabless?
    • Being able to isolate roles (especially employees versus employee-students, etc.)
      • Being able to search for content in addition to having tabs might help bring the best of both worlds
    • "below the fold" - users don't like to scroll - if they can't see it directly on the screen, they tend to ignore it
    • topic based  (eg. Academics) - sometimes can become so overwhelming on one topic it can be difficult to find things, where other areas might be really sparse
      • Combine topics plus roles - filter the results on the topic area based on your role
  • Key is making the portal flexible - ability to reorganize content easily based on improvements/user feedback/etc.
  • Being able to making gadgets for iGoogle/Facebook/etc.?
    • Protecting user privacy and ensuring that the user is who they say they are/enlarged plane of attack because of bugs in APIs, etc.?  FERPA.
    • Trying to support multiple platforms and APIs (eg. I don't like iGoogle, I use my Yahoo!, etc.)
  • End-user portlet development?
    • How do you vet it into your core portal
    • Making sure it's secure, supporting the code down the road
    • Developing an API for your portal for end-users to access?
  • Third-party content creation
    • Being able to send targed messages to specific groups of users instead of blanket messages to all users
  • "Squatter" portals
    • Installing a new piece of software that wants to provide its own "portal" and the owning group wants that to become the campus portal
    • "loose integration" - still have to log into the official campus portal and then can pass credentials through to the tertiary portals
  • No labels