Net, php, Ruby, etc. Integration with other enterprise systems is ... developer or administrator create the appropriate
Beyond Portals: A Next Generation, Action-Oriented Service Delivery Platform for Rich Campus Applications Jim Helwig, University of Wisconsin-Madison
Intro I’m Jim Helwig, Lead Strategist for the MyUW service at the University of Wisconsin-Madison. For the last 15 years I have been working in the higher ed portal space. Over this time we have gone a long way in helping the campus community find their way in the digital world, yet why is it sometimes still difficult for some users? Over the next 40 minutes we can examine this space and I hope that by the end of this presentation you will see that perhaps we can reframe the problem and continue to take great strides in providing a better experience for our campus community.
The campus digital landscape How many of you would agree that the campus digital ecosystem has become increasingly complex? Raise your hand if the number of applications, websites, systems, and other digital resources continues to increase on your campus? I think we can all agree that this presents a challenge to our campus community. Our users would benefit if we can help them navigate the digital landscape. Personally as an employee of the university, don’t you want it to be easier? In many ways, there are similarities with how things were a decade and a half ago. Portal frameworks were meant to help with with this - what happened?
Legacy portal Portals came of age around the turn of the century. No, not that century. Just as today, the digital campus was expanding. Campuses were deploying an ever growing set of web sites and web applications to meet various needs of first students and then staff. Enrollment, learning management systems, library resources, dining services, email, calendar, campus transit, student finances... and on and on. The campus portal was an attempt to make sense of the growing number of resources and applications available on the web. Everything in one spot. Portal frameworks promised to not just be a web page full of links, but to display valuable content as well. A user could see all manner of information displayed on a single page. No more trying to remember the URLs for a dozen or more web applications; no more clicking around in silos. Everything was presented in one organized web portal. But the last decade and a half produced mixed results. Part of the problem lay in that integration with ERPs proved to be challenging. While there were integration standards defined, they were never fully implemented in many source systems.
But with effort, you could deploy useful solutions. At UW-Madison we first implemented our campus portal using a commercial product but then switched to the open source uPortal product to regain more control over our destiny and jump off the vendor forced upgrade-and-pay-more-licensing path. With this platform we successfully deployed a portal that served over 100,000 users logging in over a million times each month. With the same infrastructure, we serviced all the campuses throughout the UW System. We had over 80 portets pulling content from a wide variety of systems. By many measures, our campus portal was a success. Perhaps one could argue a little too successful. As more and more units wanted to integrate content into MyUW, we increasingly had a hard time determining where to put the content. Everyone wanted their content to be on the default layout and most wanted it on the first tab. Our tabs were getting increasingly long. On the user side, there was the problem of determining which tab had the content you were looking for. We reorganized the portal several times trying to find the right categorization but what made sense to one person was not intuitive to another. The problem became increasingly clear during focus groups when we would ask students about content was particularly useful only to find that seniors were completely unaware of it. One example really hits home. On the Madison campus we love learning management systems. We can’t get enough! We currently run multiple Moodle instances, Desire2Learn, and Canvas. And this doesn’t include all the one-off sites that faculty will set up themselves. Of course this was confusing for students but we developed an innovative portlet that pulled together critical information about all of their courses. In addition to schedule, location, instructor contact, textbook, and course resources, it had a direct link to the course site within the appropriate learning management system. But when we would ask for feedback on MyUW and the My Courses portlet, It was depressing to hear seniors say, “Wow, I wish I would have known about this back when I was a freshman.” They had no idea it was there. Our portal was kind of like the typical garage: there is a lot of stuff in there and much of it might be useful, but no one really knows what is there and in reality, only the car and lawn mower ever get used.
Redesign based on user needs So we knew we had a problem and we looked for help. Our division had recently hired a user experience lead, Phyllis Treige, and we reached out to her for assistance. At the time we believed this was simply a matter of improving the organization of the content within MyUW. She led some focus groups and very quickly determined that was not the issue. Reorganization would not help. Each user had their own interpretation on how things should be arranged. Phyllis recommended that we embark on a full redesign. Our leadership agreed and gave her permission to start from square one. This freed her to approach our users in a more open matter, asking them what they were trying to do each day within the digital campus. Without mentioning MyUW, she asked them what actions were they were trying to take. How did they go about it? What roadblocks or problems did they encounter? How would they like to accomplish the task? What would be ideal? It is important to note that this line of inquiry is very user-focused. Instead of focusing on the technology or systems, these questions focus on what users were trying to accomplish. This was a major shift for us. It was no longer focused on nouns like “portal” and “student information system.” The inquiry was focused on verbs and outcomes; what actions were users trying to take?
To bring this closer to home, I want to take ask you these same questions. Take a few minutes to think about these questions from your own personal perspective as a regular campus employee. I know we have just been talking about portals, but set that solution aside and free yourself to think beyond portals. Focus on the actions and outcomes. ● What do you find yourself trying to do in your campus digital world? ● What challenges are you personally having? ● How would you want to accomplish taking action? Take a moment or two to think about these and I will ask you to report out. For bonus points, answer these questions from the perspective of a student. What actions are they trying to take? What might their challenges be? What might be their expectations on how this should work? Let’s take a moment to collect some of these. The feedback we received from our students and staff was enlightening. Respondents were task oriented and focused on the outcomes they were trying to accomplish. Users have a particular task in mind that they would like to quickly accomplish and move on. But it remained challenging for them to quickly take action. There was too much content both in the portal as well as generally across campus. It was too hard to find things. Sometimes they would miss important deadlines. The campus digital landscape did not seem personalized to them. What did they want? They wanted to find things in the same way they find other things: through an effective search engine. They want it to be more personalized, filtering out content that does not apply. They want to be notified of important deadlines. And they want it to work on their phone. We are in a unique position to try and deliver on these. We have some strengths that Facebook, Instagram, and Twitter don’t have. We should simply focus on helping our users perform activities that are unique to our campus that we were in the best position to deliver. There were some core strengths that we had. ● We are contextualized. Users would come to MyUW when they wanted to work on something related to our campus. ● We are personalized. We know the identity and roles of the members of our community and can create a unique and personalized experience for them. ● We are customizable. We may know that you are both a student and an employee, but only you know what is the most valuable content for you within MyUW and can optimize the presentation accordingly. It felt refreshing to approach the redesign with a focus on solving user problems and the goal of making their campus experience easier. To recap, we have identified that users are still facing challenges in navigating the digital landscape on our campuses. So what can we do to leverage our strengths and address these?
Take advantage of new paradigms A lot had changed in the digital world since the first portal user interfaces were design. As we redesigned, we were able to take advantage of new paradigms that are common today, particularly the growing prevalence of mobile devices. Remember, mobile technology back in 2000 looked like this. There were four in particular. ● Search - When you want to do something online but you don’t have the site bookmarked, what do you do? Search for it. I don’t know about you, but I have only bookmarked perhaps a half dozen campus resources. The rest I search for, generally using our campus search. I am almost always quickly find what I need. ● App store: When simply looking at a website is not enough and I want to quickly access dynamic information on my phone or tablet, I often check the app store to see if there is something available. ● A customized home page - When I use an app a lot on my phone or tablet, I add it to my home page. ● And finally, notifications - when I see a little number in the corner of an icon or at the top of my screen, I know there is something I need to pay attention to. We took advantage of all four of these paradigms or design patterns in the redesign of the new MyUW. This makes the user experience a familiar one, especially for our students. In fact, when we rolled it out, we displayed only a single introduction graphic that linked to additional information about the design. Most people were immediately able to utilize MyUW without issue. There was surprisingly little negative feedback, other than the few, “I liked things the way they were” comments. Because this new design uses familiar constructs, it is intuitive to our users. As part of this redesign, we acknowledged that MyUW was not a destination. It is more of a gateway, directory, or launch pad. Our campus community uses us to quickly take action; they don’t linger about. Search - click act, and then back to the important things in life.
Others also recognizing the need for a redesign As we were developing this design, others were reaching similar conclusions. Indiana University also found their legacy portal was no longer meeting user needs and they developed One.IU with the motto of search, click, done. This is a virtual app store with hundreds of entries that link users to the appropriate system for accomplishing their task. Their underlying technology has been commercialized in a cloud service by a vendor and has been adopted by a number of other universities.
Tour of the new MyUW I’m going to focus in more detail on our implementation at the University of Wisconsin, first with a tour and then with more specific information about the technology. As we take a look at this new design, keep in mind the problems you were trying to solve. Would this design help you take action more quickly? We adopted a mobile-first strategy and leveraged the four new paradigms I mentioned. Just as when you unlock your phone or tablet, when you log into MyUW you see your home page. Because we know your
identity and campus roles, we are able to present you with a default selection of widgets we believe will be the most useful.
The widgets themselves can be glorified icons or contain dynamic content. I can quickly see whether or not my latest payroll statement is available, what the balance is on my Wiscard, or if there are any new scholarship opportunities. If I need additional information than what is displayed in the widget, I can click on the widget to access the corresponding app. Apps have access to more real estate and can show more information.
If I don’t see a widget relating to what I need, there is a prominent search bar. This search aggregates results from the catalog of apps within MyUW, the campus directory, and the campus search engine. If there is not yet a related app in MyUW, chances are a useful link will show up in the campus web search. If I see an app that is useful I can either access it immediately or add it to my home page for quick access later.
I can easily rearrange things on my home page to put the most useful things above the fold. I can switch out of expanded mode if I want to see more widgets without the dynamic content.
MyUW is also fully responsive so it scales down appropriately on a mobile device.
You’ll also notice the notification icon in the MyUW header. By clicking on that, I can see the list of unread notifications. We have developed a set of guidelines for notifications and are reserving this space for action-oriented, important notices.
Critical notifications are immediately displayed above the header for increased visibility. For special announcements, generally related to new available within MyUW, a whimsical macot peeks out in the header. Clicking on it displays a brief announcement with a link for more information.
One of the notable differences of this new design is that there is relatively little on the default view. We got rid of tabs. The emphasis is on search and customization. The user isn’t overwhelmed with an overload of content, most of which is not relevant to the task they are trying to accomplish. Another benefit of this design is that it scales beautifully. There can be hundreds of widgets, apps, or pieces of content but searching immediately narrows it down to those that are the most relevant. Our system has scaled well as we expanded it to serve the other dozen campuses across the University of Wisconsin System. Each campus has it’s own skin and can contain content specifically targeted to that campus. A number of these campuses are starting to leverage the framework to develop additional content to include.
After seeing this tour of the functionality contained within this framework, think back on the actions or activities you identified earlier. Would this design help you more easily reach the outcomes you wanted? Does this user interface seem intuitive? Is this a better user experience?
Pull back the covers, architecture and technology So that is the user facing side of the solution. I did want to briefly lift up the hood and take a look at the underlying architecture and technology. What I describe here is open source and freely available for you to take a look at and consider adopting some or all of the design or actual code.
We had been using the open source uPortal platform for over a decade and built this on top of that to leverage much of the work we had already developed. Essentially we built an alterternative frontend to the current system. Since we use angularjs, we call it angularjs-portal. The code is public and freely available under the Apache 2 license. It has been submitted to the Apereo incubation process and is expected to be included in uPortal 5, the next major release of uPortal scheduled for next year. What I describe here is the fullest implementation that includes notifications, dynamic widgets, and custom apps. By no means does a campus have to implement all of this. As we embarked on implementing this redesigned user interface, we found ourselves also redesigning the architecture. While legacy portal system technologies did vary, in general they were fairly heavy weight, typically running in one large container and generating all the HTML or markup on the server side. Now we are able to take advantage of technology and framework advances that have emerged over the last decade. In our new architecture, we more distinctly separate the frontend and backend. The frontend is primarily Javascript and CSS. There are many open source libraries and frameworks that make this user interface development much easier. This code is responsible for displaying to the user the information it receives from the backend. The data is delivered as JSON over REST web services. Instead of having one big backend system implementing all the web services, we can further break them down into microservices. Each microservice can be an endpoint that implements a logical, self-contained API. Furthermore, these microservices can be packaged using container technologies like Docker which can in turn be deployed on various physical or virtual servers. This gives administrators a lot more flexibility in managing systems for high performance and reliability. This decomposition and separation of concerns results in greater flexibility when it comes to developing and managing the system. User interface developers can be very effective on implementing the visual frontend without have deep knowledge of the technologies used to develop the backend. Technologists with a more traditional skillset can focus on developing backend systems without having to worry about keeping up with the
lastest UI toolkits. Additionally, these backend web services can be implemented in any language. A system could include a mix of backend services implemented in Java, .Net, php, Ruby, etc. Integration with other enterprise systems is focused on developing the necessary data feeds. If the system does not natively support JSON and REST, a thin shim service can be implemented that would access the data in whatever legacy API was available: SOAP, PLSQL, flat files. If you have an ESB or enterprise service bus available, it can often handle this translation without having to develop and operate a custom service. This architecture allows the user interface for the separate apps to be simple one-page apps. The JavaScript dynamically generates all the necessary visual components for even more complex applications. To help produce a more consistent user experience across applications, we deliver a framework that application developers can use as a base for their implementation. This includes the header and footer and the common look-and-feel. They can focus on the rest of the interface that is specific to their application.
Examples of adding content As I mentioned, this lays out the complete architecture but is not required to get started in this post-portal world. Simply having a collection of links to external systems would not require additional backend development. It simply involves configuring a widget with the relevant metadata. Other widgets that can be created simply through configuration include lists of links, news feeds, and search. We have a tool that helps a developer or administrator create the appropriate configuration file. It you want to create more interesting dynamic widgets or custom apps, you need to implement additional microservices to deliver the appropriate data.
A number of groups on the Madison campus and throughout the UW System are going beyond configuring widgets, implementing full apps on top of this framework. They are able to leverage much of the user experience work that has already been done to create an app that appears to be seamlessly integrated. This provides the users with a more consistent and user friendly experience. One example is an enrollment front end built that shields the user from the backend student information system.
Another example is our Advising Gateway. This is more of a dashboard application that aggregates data from a number of backend systems into one easy to user interface. By asserting ownership of the user interface instead of simply taking whatever the various vendors offer, we are able to create an effective tool that better suits the needs of our users.
Key observations Stepping back, what are some of the key observations of this post-portal world? It’s not about the technology; it’s not a destination. What we are talking about is really a gateway, strategy, or service that helps users quickly find what they need to take action. It’s identifying and prioritizing actions that your campus community are trying to take and creating a curated set of cards or widgets that are contextualized to your campus and perhaps aware of the roles a person has.
It’s finding that balance of surfacing the most important information while not cluttering up the user interface.
Next steps So what are some next steps that you could consider taking? ● Conduct surveys, focus groups, and other user research to identify and prioritize the core actions or activities your users are trying to perform. ● Look at technologies you can leverage to help implement a solution. I mentioned one cloud based vendor service. You could collaborate with UW-Madison and the open source Apereo community. Or you could simply use well-indexed static web pages that contain links to the services. ● Start simple: Search, click, act.
For more info On MyUW: https://it.wisc.edu/services/myuw/ Angularjs-portal docs: http://uw-madison-doit.github.io/angularjs-portal Angularjs-portal code repository: https://github.com/UW-Madison-DoIT/angularjs-portal Jim Helwig
[email protected] Link to this presentation: Slideshow version: https://goo.gl/vW6wDm Document version: https://goo.gl/PKsFQx
