Abstracting the UI Layer for WebSphere Portal
 

Abstracting the UI Layer for WebSphere Portal

on

  • 144 views

Presenters: Brad Nunnally, WX Solution Architect, Perficient & Shyam Sunter, Technical Solution Architect, Perficient ...

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.

Statistics

Views

Total Views
144
Views on SlideShare
144
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Abstracting the UI Layer for WebSphere Portal Abstracting the UI Layer for WebSphere Portal Presentation Transcript

  • 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 View slide
  • Design Team Visual Designer(s) Front End Developer UX Architect Project Team | Design Team 4 View slide
  • 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 brad.nunnally@perficient.com @bnunnally www.perficientxd.com Shyam Sunter – Senior Architect, Portal Solutions shyam.sunter@perficient.com www.perficient.com 44