Simplify Portal for Adoption

1. Less is More: Simplifying the Portal to Drive Adoption Ernie Soffronoff and John Ferrell Robert H. Smith School of Business University of Maryland, College Park

2. Table of Contents • Who are we? • Introduction and Context • A Quick Look at Technology • Why are you here? • What’s in it for you? • Lessons learned the hard way • Pre-Implementation • Phase One • Phase Two • Phase Three • Think about having less of… • Think about having more of…

3. Who are we? • Ernie is the Associate Director for Technical Operations, and built the first several versions of the eSmith portal. He’s now just a manager. • John is the Manager of Enterprise Systems and built the last revision of the portal. He does what Ernie tells him to do. • We are from the Robert H. Smith School of Business at the University of Maryland, College Park • 500 faculty and staff • 2,000 MBA students • Approximately 8,000 undergraduates enrolled in classes each year • Classes at remote campuses in downtown Washington, DC, Shady Grove (DC suburbs), and Baltimore • Executive MBA programs in Beijing, Zurich, Tunisia

4. Introduction and Context • The eSmith portal started as a vision document for what an education portal might do for the school – originally everyone, but ended up focusing on faculty and students • Intended as prototype for a University-wide portal • University had a terrible identity problem – up to 13 separate accounts – but had just finished an LDAP directory project

5. A Quick Look at Technology • The University inherited software licenses from State of Maryland project in 2001 • iPlanet 3 Portal, ATG Dynamo application server, Autonomy search engine • Blackboard Course Management Software • Later acquired Tarantella • Later replaced Tarantella with Citrix • Sun Solaris back end servers for portal • Lotus Notes and Novell Netware

6. Why are you here? • Not enough people are using your portal – there never are! • You’ve done everything “right” but you still aren’t getting the anticipated usage • Your people (users or administrators) just aren’t “getting it” • You’re too close to your project to see the problems • You’re getting pushed around by people who have more say than sense • You don’t want to repeat our history

7. What’s in it for you? • First, look elsewhere for best practices about targeting users, getting executive buy-in, peer collaboration, etc. That’s important, but well documented. • For people who are still pre-release, maybe not so much. • Look for the patterns in your own lack of adoption (everyone could do better…) that might be reflected here. • Why are you building everyone else’s portal, when others are already doing it? Trash the definition! • There are things you need less of, and things you need more of!

8. Pre-Implementation – 2001

9. Pre-Implementation Definition • A portal is a secure, highly customizable web site that offers a broad array of tools, information, and services. • Development focus on figuring out user provisioning, flexible presentation, research engine, collaboration tools, and “portal stuff” like weather and stock quotes. • Real focus was on getting something, ANYTHING, out the door.

10. The Essentials Page – First Web

11. The Essentials Page – Concept Watercolor

12. The Essentials Page – ASCII on TTY

13. Pre-Implementation Results

14. Pre-Implementation - The Result? • Web designer doesn’t “get it” – colors are horrible and lots of non-scalable graphics – it looks terrible • People are promising things that cannot or should not be delivered. Can they be stopped? Actually, no… • In demonstrations to deans, absolutely nobody “gets it” • Creeping dread… Does anybody need this? • Divided attention for implementation team – Blackboard, portal, and Autonomy all being implemented by one person.

15. Phase One – 2002

16. Goals for First Public Release • Emphasis on search agents and sophisticated research tools • Emphasis on collaboration, including tools for conferencing, chat, and remote file access • Some customized content / tools based on role (faculty, staff, or student) and user • Lots of “portal stuff” • User provisioning very rough – cross-system identity management was very weak

17. Early 2002 – First Implementation

18. The Essentials Page – First Public Release

19. Research EngineSave refined searches as agents

20. Research EngineAgents can be shared and maintained by groups of users

21. LOTS of Plugins Required

22. Phase One Results

23. Phase One - The Result? • Resounding silence… our “killer feature” didn’t make sense to faculty • Beyond research, students and faculty really didn’t “get it” – they already liked Google, MyYahoo, Marketwatch • Found the rest of the technical infrastructure (Notes / Netware) wasn’t ready to support Internet front end • Browser plug-ins were a major hurdle – compatibility problems and enforced browser requirements • People didn’t see the immediate value, because they didn’t see something right away, or because they had some incompatibility such that they couldn’t see value

24. Phase Two – 2003

25. Phase Two Definition - 2003 • A portal is a secure, highly customizable web site that offers a broad array of tools, information, and services. • Development focus on providing applications to users. • Hopefully most apps will become web-based.

26. Phase Two Remix • Tarantella added to bridge gap until all applications were web enabled • Redesigned look – tabbed interface, fix the colors • Autonomy research tool removed • Identity management much improved • Content channels of “portal stuff” pre-populated based on affiliation (department, student program) as well as role • Quick view mail using iNotes web client placed front and center

32. Phase Two Results

33. Phase Two -The Result? • Help desk tickets describe horrible compatibility issues • Tarantella required 3+ MB JAR, very specific Java versions, and access on port 8080, and a pop-up window • Microsoft had removed their JRE from Windows, and the current version at Sun was incompatible • ActiveX viruses running rampant • Pop-up windows being indiscriminately blocked by first generation of pop-up blocking software • People – most importantly, our dean – HATED the iNotes web mail application, the most prominent web app on our site – and wanted their fat native applications • In usage surveys students were asking for things it actually already did… • When it worked, though, people were starting to get the concept. They liked access to the Notes client, and loved remote access to the database applications otherwise unavailable.

34. Phase Three – 2004

35. Phase Three Definition - 2004 • A portal is a secure, highly customizable web site that offers a broad array of tools, information, and services. • Development focus is compatibility, and to center attention on only the most popular features. • Make user experience more seamless through better identity management.

36. 2004 Remix • Simplified interface to focus attention • Fewer tabs • Remove all the “portal stuff” • Remove all non-tool content • Remove all layout controls from user – channel layout is the same for all users, though content might change • Add new school-wide calendar tool • Remove all client side Java dependencies • Further refinements to identity management • Remove portal gateway component for speed and IP port compatibility • Replace Tarantella with Citrix to deliver remote applications – Citrix provides tighter integration with Netware backend and no Java client requirement

39. Phase Three Results

40. Phase Three - The Result? • People “get it” even without any orientation or training – they understand what the portal offers, and make reasonable requests for specific enhancements. • People see the immediate value, because there really isn’t anything else left. • Heavy Citrix client is much easier to maintain than a browser-based client – far fewer help desk tickets. • Is used as only option in some remote-location classes. • The proof is in the usage…

41. Usage Stats 2002 2003 2004 2005 Enterprise Application Stats eSmith Portal # of Registered Portal Users 500 1567 2683 5759 Avg. # of Weekly Portal Users 613 Avg. # of Weekly Portal Logins 3325 Avg. # of Concurrent Users 5 - 8 20 35 60 Citrix- Remote Applications Avg. # of Weekly Citrix Logins 1230 Avg. # of Weekly Citrix Users 253 # of Remote Portal Applications 5 14 40

42. Usage Stats – A Fresh Group of Users • Since 2004 Remix –Two 16 week periods: • Sun Feb 13, 2005 - Sun May 29, 2005 averages: • 2746 logins per week • 458 unique users per week • 743 Citrix logins per week • Sun Feb 12, 2006 - Sun May 28, 2006 averages: • 3341 logins per week • 590 unique users per week • 1211 Citrix logins per week • Moral: People graduate, so even if you did it wrong memories can be short.

43. Less is More

44. Less • Less adherence to the definition of “portal” • Do people want a portal, or the things found in your portal? • Less “portal stuff” that people are probably already viewing elsewhere • Less reliance on users to customize their own workspaces • Less distractions from what makes your system different • Less “stuff” that isn’t core to what your system can uniquely do (information or link boxes) • Less stuff “below the fold” – they won’t customize, will they even scroll? • Less client side dependencies (Java and other browser plugins) • Consider fat clients instead of plugins • Less concentration on customized content • People don’t read it anyway… • If you really think they will, it might be better suited for an RSS feed that can be used on other pages or on different devices

45. More • More “seamless” integration • Strong identity management – work hard to guess passwords and accounts, so channels can function on first user login • DON’T depend on users to configure their channels • More of what people really want • If they want Google, even though you’re providing Autonomy, give them Google • More focus on the things only you can provide • More ability for users to create their own workflow • Does everything have to start and end on the portal page? • Do you really have to login to the portal first? Why not treat your application logic like any other protected content, and allow linking to the application. • More willingness to give up on the things you maybe like the most, or that were the hardest to implement

46. So what’s next???

47. iPhase version X Web 2.0 rev.1(The Future!)

48. If you’re not asleep already… • You still might want to go to sleep if… • You have applications tightly integrated into your portal (lots of data push / pull) • Or, in other words, lots of work is actually done IN the portal, rather than around the portal • You are central IT, own everything, and can change anything

49. If you’re not asleep already, then finish the destruction! • What happens if… • You believe people are going to keep using the tools they’re used to using • People keep bugging you about integrating one tool into another tool • You really like some of the new personalized home page tools that are becoming so popular • And if… • You remove identity management from inside the portal and put it next to the portal? • You remove session management from the portal, and put it next to the portal? • What is left?

50. Demo