Join the List!Join the email list!
Join the JA-SIG User Experience email list and continue the discussion of this BoF. SummaryWhat are people working on?- D&D uP2 customization
- Split Content Subscription/ Selection
- Locked down user customization
- New Theme/Skin
- uP3: Pretty, Compelling, Demos - D&D
- uP2: HEAD, XHTML, others
- Portlet Content - CSS classes (usage)
- Skin selector on page - RIT gave back?
What do peole want?- Accessibility
- Easier to add Content, Customization
- Facebook?
DiscussionIntro: Product is powerful but complicated, technically interesting but polish issue, default presentation is dated to ugly, a lot of UE work at institution level rather than project level, like myRutgers, MUN, UW streamlined workflows, but base UE of portal hasn't changed a lot competitive pressures, Google Liferay D&D user expectations have increased websites can do this so they want our institutional IT to be on a similar level in terms of UE open floor to discussion Gary: let's hear from Fluid project Slides by Colin Clark from Toronto: George L. re UBC webmail
approach that UBC is looking to take with lots of channels common navigation features, nav on left side, upgrade to consistency Gary: really enjoyed having UBC-Webmail wireframe come out to where people can give feedback, thanked G Lindholm for sharing it Jason: Lots of developer teams, model of sharing wireframes helps local planning process as well as project. g L: initial approach was very UBC-specific, webmail is a multisite project, seeking feedback Colin Clark: Overview of the Fluid Project
Inclusive Software Architect
Adaptive Technology Resource Center (see ppt slides) looking to build cross-project skinning support, general layer. create exemplary UI components. Reusable bundles of UI real estate. Composable.
Impl: DHTML with JavaScript & AJAX. Colin will post to lists
on these topics. Jason: What are people doing? Jen/Yale: worked on Drag & Drop in uP2. Have others done this? Is there prior work I can use? G Lind: Drag & Drop for what? Jen: For preferences controls in DLM.
Found some prior work on ALM. Kind of irrelevant. Jen: not able to uP3 upgrade soon, looking to improve uP2 in near term. Improve channel subscription workflow. Too many clicks, too little context. Jim Helwig:
We separated concept of content selection from content re-arrangement.
Want to put something on your page. Once it's there move it around.
Partly because as previously implemented in COncentric.
Content selection page displays content, title, brief description. You just click a checkbox of what content you want to display. Lists everything available with checkboxes. Themed by tab. Put in default location, you don't need to deal with re-arranging. Implemented in a particular way. my.wisc.edu there's a demo link. Gary: Jim, do you have user testing? Jim: We've had no complaints. <laughter> We were trying to replicate what we had in the previous portal product. Probably improved a little from user's perspective, tile movement. All developers when started uP project my goodness this is terrible as uP ships ten clicks to accomplish end user preferences. Developers more satisfied. If we'd rolled out base uP there would have been dissatisfied. Jason: How many turn off customization entirely. Why? Manchester: To add freedom is easier than to take it away, start locked down, increase user customization. Markow: Locking down controls help desk support. Does not Jen: we've been considering locking it down speciifc to control support. Administrative pages. Allows helpdesk to tell people where to find it. Worried that users might delete needed channels. Jim: restrict content to particular tabs. On academic tab can only subscribe to academic content. Jen: wind up with a lot of users with only one thing on a tab? Jim: collecting stats, believe that most users do not customize. Default layout is pretty good. All available content is on default layout. People don't need to go in and add. RIchard spencer: Do you lock and unlock some tabs? Jim: at this point there's only one undeletable module, otherwise you can remove content from given tabs. Joni: How many users do customize their view? 7% Jason: Fully open MyRutgers. 35% customization. Majority of those customizations are clicking X box to delete channels, fewer new subscriptions. Why? Because users don't want to add, or because they can't figure out why? George: Highlight newly available channels? Jason: Front page of portal for announcing about portal. Deep linking / fname access to channels. Directory of channels, can access them without actually subscribing to them. One-off services or rarely accessed services. Portal as service delivery platform. ???: Under 2.1: 10%, 2.4: 30% modified. Jason: bear in mind some users may have tried a chance and then undone it, still appear as modified in stats. Someone want to talk about uP3 skin? G Thompson: Unicon provided effort skin in uP3, out of box appeal, compelling. Effort that happens in getting uP accepted at your institution. can I get people to look at it? Help to address encouraging initial interest in uP. New version theme-wise. Start from web standards accessible under hood setup easy to customize. Breakout to a config file without gutting the main theme file. Customizations may be limited to one file. Jason: Head of uP2 has genericized version of uP2 Rutgers skin. XHTML, standards-compliant, CSS-based. Prob not as modular was what Gary described. Intended to become presentation layer for uP 2.6. A number of sample skins. George: issues with that presentation, color schemes, cannot read error message. May be some regressions? Jason: There are probably regressions and bugs. Let me know of issues. Anthony: Portlet content. JSR-168 spec for CSS classes, very minimal recommendations. Conclusion: out of box portlet markup always inconsistent. With opensource portlet can locally change UI. Jason: ootb JSR-168 css spec insufficient. Gary: tried as much as we could to use JSR-168 css spec, but does not cover the necessary number and breadth of classes. Anthony: is there value in the community stepping up to this problem? Gary: good idea Jason: we developed internal spec, standards, semantics building on JSR-168. Clear split between stuff inside the box and stuff outside the box. Better at defining theme styles, inside channels things get fuzzy. Maybe that's correct, maybe we need flexibility per-portlet. RIT: We have a skin selector on front page so folks can choose among 5 skins. Magic link that goes into the preferences, through all the motions, and back out. We may not have shared the code. Aaron: Have people heard interest out of user base for user-contributed skins? Skin development kit for users? RIT: We did that, contest, gave away an iPod. We had a couple good ones. JHU: We did the same thing, had a contest for portal skins, put it in the selector but didn't make it a default. Jason: Changing the skin is part of release cycle. Not a lot of work, but high visibility and raises excitement. Markow: People want to enjoy their user interface. Jason: our Users do want the sense of empowerment. Can customize. Adjust as appropriate for workflow. It's like fashion snapplates for cell phones. Markow: Improving the clearinghouse portal, right now it's just about nonfunctional. If we had a Jason: too much customization occurs to the individual themes. Hope to converge on theme, or set of themes, or markup conventions, so that we can share skins. Aaron: Approach we took with our most recent upgrade. Normally very hackish. This time, use existing naming conventions in 2.5.3 and triple number of classes, ids, so forth, added comments. Tried to make it easier for future to just have single css file defining skin. Jason: hopeful if you look at the head of uP2, hoping it is sufficient or can evolve to be sufficient to coalesce on common conventions and move up the stack to skins. Gary: Accessibility issues, concerns about how accessible your portal is? Aaron (Dennison): Haven't traditionally, but probably start piloting portal for alumni. Alumni have accessibility concerns outside traditional accessibility concerns. Type size. Jason: Starting to look at slightly impaired users. High contrast, large text skin. Get the easily helped users first. Screen readers a hard problem, current institutional solution is to hire people to assist disabled users. Aaron: Trying to write good markup and css. It's one thing to get tab flow to work : Invested a lot in ALM, how do we now migrate that to DLM? Jason: It shouldn't be that hard to do a conversion, easy to accidentally run DLM skin in ALM. : We did a lot of testing with complaining users and with impaired users, things are looking good on that front. One theme for all audiences, disabled and not. Jason: Have you gone through your channel content as well? Our chrome is likely accessible, but content within the channels gets dicey. : Especial challenge if disparate group developing, maintaining content items. Need to educate. JHU: Very decentralized, very disparate groups. Institution-wide accessibility group meets quarterly. can't fix everything. (Major vendor product) is never going to be accessible. Going after low hanging fruit. : Guidelines for accessibility. Portal infrastructure team as gatekeeper. QA check before deployment. Will not allow components that do not meet minimal accessibility guidelines. Jason: I18n? Localization? Is this a big concern? Eric: Some of the portlets we're using now are using resource bundle for the text. Nice in other ways to do localization w/o the i18n. : You mentioned users not adding content to portal. Our focus groups told us people don't want to go to another screen to add content, customize layout. made add content always available. because user customizations right there all the time people more likely to use them, move content on screen, add content. Auto-add to upper left hand corner, from whence you can move it. Jason: What customization rate do you have? : We've done just a pilot. Influenced people to try to change things. It was easy for them to change, didn't have to walk them through it. Without training or instruction users able to customize. Aaron: I think the customization issues that we have, don't want to say problems, it's a usage pattern. A lot of folks don't get the customization paradigm. People tell us users have expectations from other portals. But tehy seem to see the site as a slightly richer webpage. Maybe not a good job done advocating and educating, wait for culture shift? Markow: Maybe you've gotten it right out of the box? Fluid: Maybe move customization into the software itself. let software bend itself to accomodate preferences. Auto-customization based on click patterns, interests. Jason: As second tier support for the portal, I want to guarantee consistence, experience not evolving. If they can't understand why it changed, it's broken. It's a challenge. We have channels that are different by role. What does UE customization enhancements imply for support? Fluid: Let's focus customizations on the valuable ones. More choices don't necessarily make it better. Jason: Who here is a facebook user? 80% of our students have a Facebook account within six months of arrival on campus. Facebook is interesting, geared toward social networking, pulls notifications of social network change into your view. Actionable intelligence. Portal adjusts to your needs, allows you to take action. JHU: Connecting to existing services. Suck in peoples' facebook information? Jen: There's an alternate portal at Yale, created by students, hooked into facebook, rich set of shared groups and calendars, local city information. Spencer: Should the portal be doing this? Jason: we've been focusing on service delivery. Spencer: Leaving aside social and moving to administrative, some other application should manage notification and use portal to deliver it. Jason: From an architectural standpoint I agree. From a UE standpoint, I don't think the user cares. Spencer: BYU: Trying to roll out university-wide content management. Anyone doing that in a portal? Aaron: What do you mean by that? We're starting offering content in portal and capability to edit it in the portal. Jason: We've tried to toe the line that this is not the Rutgers website in little boxes. But admitedly, our users do like the fact that we have links, that we're almost a content or services directory. Jon Atherton: JHU: uP is very flexible in terms of drawing in content from existing sites. WebProxy, IFrame, XSLT. Jason: I don't want to cut things short but it is lunch time. |