Presenters: Brad Nunnally, WX Solution Architect, Perficient & Shyam Sunter, Technical Solution Architect, Perficient Using a project implementation example, we review the various methods the team used to build out this abstracted UI layer. Understand the lessons learned from their journey and the recommended approaches for managing Dojo element, and enabling separation of the HTML, CSS and JavaScript from the WebSphere Portal code so they can maintain, update and test front-end enhancements to a continuous deployment mode.

1. Abstracting The UI Layer
IBM Digital Experience
Brad Nunnally
UX Solution Architect
Shyam Sunter
Sr Architect, Portal Solutions

2. 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

3. Section 1
Team Makeup
3

4. Design Team
Visual Designer(s)
Front End
Developer
UX Architect
Project Team | Design Team
4

5. Project Team | Development Team
5
Portal Development
Team
Portal Developer
Architect
Services Developer
(APIs)

7. 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

8. Section 2
Problem Solving
8

9. 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

10. 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

11. 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

12. 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

13. 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

14. Section 3
What & Why
14

15. 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

16. What & Why | Layers of User Experience Design
16

17. What & Why | Old School Web Architecture
17
Presentation Layer
Structural Layer
CSS
HTML

18. What & Why | “Web 2.0” Web Architecture
18
Presentation Layer
Structural Layer
CSS
HTML
Behavioral Layer JavaScript

19. What & Why | Modern Web Architecture
19
Presentation Layer
Structural Layer
CSS
HTML
Behavioral Layer JavaScript
Content Layer Database APIs
Contextual Layer CSS &
JavaScript

20. 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

21. What & Why | Modern Web Architecture
21

22. 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

23. 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

24. 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

25. 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

26. 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

27. Section 4
How and What?

28. 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

29. 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

30. 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.

31. 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

32. 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

33. How & What | Technologies Still Evolving
33

34. 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

35. Holistic Digital Experiences – Disney Experience
35

36. Holistic Digital Experiences – Square
36

37. Holistic Digital Experiences - Squarespace
37

38. Holistic Digital Experiences - Harvest
38

39. Holistic Digital Experiences – Bolt Bus
39
Perficient Project

40. Holistic Digital Experiences – Patient Portal
40
Perficient Project

41. 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.

42. 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

43. 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

44. Thank You.
Brad Nunnally – User Experience Solution Architect
brad.nunnally@perficient.com
@bnunnally
www.perficientxd.com
Shyam Sunter – Senior Architect, Portal Solutions
shyam.sunter@perficient.com
www.perficient.com
44