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
@bnunnally
www.perficientxd.com
Shyam Sunter – Senior Architect, Portal Solutions
www.perficient.com
44