Abstracting the UI Layer for WebSphere Portal

Abstracting The UI Layer IBM Digital Experience

Brad Nunnally UX Solution Architect

Shyam Sunter Sr Architect, Portal Solutions

Opening | Project Background

2

Project Scope:

•  Patient Portal for Largest Hospital Network in US

•  Responsive Design for Mobile and Desktop

•  Built on top of WebSphere Portal

Projects Goals Included:

•  Instant Access To Medical Records

•  Review of Lab Results

•  Collaboration with Medical Staff

•  Scheduling of Events

Section 1

Team Makeup

3

Design Team

Visual Designer(s)

Front End Developer

UX Architect

Project Team | Design Team

4

Project Team | Development Team

5

Portal Development Team

Portal Developer

Architect

Services Developer (APIs)

Designer(s) Wanted Control of the UI Layer

WebSphere Portal’s theme framework ensures that designers have to rely on Portal Developers to integrate and release UI changes.

Opening | The Problem

7

Section 2

Problem Solving

8

Make Quick and Frequent Updates to Front End Design

Due to frequent changes coming from the business stakeholders, it was necessary to update the front end design without the bottleneck of portal developers.

Problem Solving | Desires VS Ability

9

Work Through A Remote Development Team

After creating the source UI code, it was delivered to an offshore development team to incorporate in the development backlog for the sprint. Small changes took up time and resources which would have been better served building new functionality.

Problem Solving | Desires VS Ability

10

Why our desires mattered?

The design team wanted control over the UI Layer to free up time for Portal Developers, but also to quickly address ever changing requirements.

Problem Solving | Why this was important?

11

What roadblocks did we run into? 1.  This was a new technique for both the UI developers and the Portal developers, so it

required several proofs of concepts and time to research available technologies. 2.  The Portal development team had very specific Java based skills. The developers had

to learn how to shift those skills to working with JavaScript based frameworks.

3.  The change in approach was decided in the middle of the whole development cycle, though it was given focus in specific sprints to create the code and proofs of concepts.

4.  The technologies are still emerging, so there wasn’t a clear choice in which framework to use to build the abstracted UI layer. E.g. Handlebars vs Mustache

5.  The development of the prototype had to occur twice, once for quick business validation and once for framework preparation.

Problem Solving | Challenges

12

What risks did we have to mitigated? 1.  The team used technologies which still don’t have a clear industry standard

associated with them. This created the risk of rework because of how frequently HTML templating and front-end MVC technologies change.

2.  The timeline and scope had to adjust to accommodate the increased costs for

development and time to address any learning curves.

3.  The development timeline was at risk due to the need to create unplanned proofs of concepts to validate the new approach.

4.  The integration of Portal and front-end MVC frameworks and HTML templating was an unknown, which made making estimates a challenge during sprint planning.

5.  Unforeseen issues could surface that would need workarounds; e.g inter-portlet and cross-page communication

Problem Solving | Risks

13

Section 3

What & Why

14

Enter The Modern Web

Web architecture today is becoming one of relatable layers and abstraction. This is a result of the move to mobile and the growing presence of cross-channel experiences.

What & Why | Modern Web Architecture

15

What & Why | Layers of User Experience Design

16

What & Why | Old School Web Architecture

17

Presentation Layer

Structural Layer

CSS

HTML

What & Why | “Web 2.0” Web Architecture

18

Presentation Layer

Structural Layer

CSS

HTML

Behavioral Layer JavaScript

What & Why | Modern Web Architecture

19

Presentation Layer

Structural Layer

CSS

HTML

Behavioral Layer JavaScript

Content Layer Database APIs

Contextual Layer CSS & JavaScript

What & Why | State of APIs

9000+ APIs Currently Available Today

20

105 352

601 1116

1628

2647 3000

7000

9000

2005 2006 2007 2008 2009 2010 2011 2012 2013

What & Why | Modern Web Architecture

21

Two Sides of Development

By supporting a dedicated front end UI layer, it brings together to two sides of development to create a modern digital experience.

What & Why | Marriage of Front End and Back End

22

We Need Control

Design is all about iterating as fast as possible to get to the best possible design for the user. To iterate quickly, the design team needs to be able to actively “play” with the design both internal but also in production.

What & Why | Control of UI Layer

23

Pushing UI Code More Frequently

The design team is able to publish in “real time”, without being constrained to develop release schedule. The team is also able to focus on collaborating on the front end code and design.

What & Why | Publishing UI Code Updates

24

The Internet of Things

The days of working only in the desktop environment are behind us. Sure, there are some stragglers, but no longer are people chained to a desk and chair.

What & Why | Cross Device Capability

25

Paying Attention To Every User

Ensuring that the code is structured and written appropriately is key to building an accessibility solution. Many easy to address accessibility issues can be addressed at the front end layer.

What & Why | Accessibility

26

Section 4

How and What?

What did it take to break the branding style out of Portal? 1.  Determine the appropriate branding and style components which was driven by

contextual source of access. 2.  The client had a CDN server set up to be used to serve CSS files based on branding

contextual source. 3.  The branding context was determined and maintained by using a combination of

cookies, session variables, and request parameters. 4.  Provided access and control to the Front-End developers to allow them to update the

branding and style elements

5.  Some aspects of the UI were delegated to individual brand team members to update and maintain

How & What | Abstracting Branding

28

What did it take to break the behavior out of Portal? 1.  The team broke the JavaScript files out of the Portal framework and stored the files

through CDN server

2.  The creation and maintenance of the JavaScript files was assigned to Front-End developers to better align with team member skillsets

3.  Using the CDN server, JavaScript files were referenced globally from the portal theme

4.  WebSphere Portal theme modules were used to render select JavaScript files to improve overall performance

How & What | Abstracting Behavior

29

How & What | More Control Needed

30

Not enough! The design team required more control

Changing the branding and behavior alone was not enough. The next frontier was the need to change the HTML structure without involving portal development team.

How & What | HTML Templates

31

HTML Template driven development was the answer

We adopted HTML template driven development and explored options of several templating frameworks. Handlebars.js was the top choice due to several reasons including high adoption, support, added helpers, and improved performance

What did it take to break the HTML structure out of Portal? 1.  Front-End developers created Handlebars based HTML templates working closely

with portal development team

2.  The team hosted the complied HTML Handlebars template on the CDN server

3.  Templates were used primarily in the portlets and not in the portal theme

4.  Various proof of concepts were built to verifying the portal features were not being lost by using the new templates

How & What | Striping HTML Out of Portal

32

How & What | Technologies Still Evolving

33

So What?

There is no such thing as a website or application anymore. There are only digital services that require multiple touch points and a dedicated user interface development team.

Closing | So What?

34

Holistic Digital Experiences – Disney Experience

35

Holistic Digital Experiences – Square

36

Holistic Digital Experiences - Squarespace

37

Holistic Digital Experiences - Harvest

38

Holistic Digital Experiences – Bolt Bus

39

Perficient Project

Holistic Digital Experiences – Patient Portal

40

Perficient Project

Merging for Design and Development

41

Merging of Two Worlds

The development of digital products is becoming ever more complicated, resulting in the need for dedicated teams that focus on the two fundamental pieces of any digital product. The front end and the back end.

Perficient At IBM Digital Experience

42

Date  &  Time     Session  ID     Topic    

Monday,  July  21  1:45  -­‐  2:45  pm   BUS  -­‐  G02  

Using  Excep,onal  Digital  Personas  to  drive  Revenue  Speaker:  Mark  Polly,  Director,  Portals,  Content  &  Social,  Perficient        

Tuesday,  July  22    3:15  -­‐  4:15  pm     BUS  -­‐  S03  

Consumer  Engagement  with  Florida  Blue  and  Excep,onal  Digital  Experiences    Speakers:    Phani  Kanakala,  Manager,  Web  and  Mobile  Team,  Florida  Blue  Glenn  Kline,  Technical  Director,  Perficient      

Wednesday,  July  23  1:45  -­‐  2:45  pm       TECH-­‐D17  

Abstrac,ng  the  UI  Layer  For  WebSphere  Portal  Speakers:  Brad  Nunnally,  UX  SoluRon  Architect,  Perficient,    Shyam  Sunter,  Technical  SoluRon  Architect,  Perficient    

Wednesday,  July  23  3:15  -­‐  4:15  pm     BUS  -­‐  G09  

Healthcare  Portals:  5  Core  Prac,ces  to  Make  a  Great  Digital  Experience  Speaker:    Mark  Polly,  Director,  Portals,  Content  &  Social,  Perficient      

Perficient Blogs

43

IBM Technologies

http://blogs.perficient.com/ibm

Portals and Social Business

http://blogs.perficient.com/portals

Spark Blog

http://blogs.perficient.com/spark

Thank You.

Brad Nunnally – User Experience Solution Architect

[email protected]

@bnunnally

www.perficientxd.com

Shyam Sunter – Senior Architect, Portal Solutions

[email protected]

www.perficient.com

44