Hi folks,
First and foremost, I would like to honestly answer the following:
Why am I writing this?
Answer:
I've been asked by ohad.yassin to do this.
Well... not exactly. It's not that we met in the elevators and Ohad just asked that explicitly, it was more part of the Blog It Forward thing,
If you are not yet familiar with this cool initiative, read about the challenge and check out the chain.
So here's a little about myself:
You already know my name. I'm 31 years old, married to Carolina and new Father of Dan, here they are (isn't he the cutest thing ever?!)
I have been working for SAP a bit more then 7 years.
During these years I have always had the pleasure of being technologically and professionally challenged as part of my daily job in the BIT Portals group. Some of my previous roles were related to test automation and test automation tools, and since Oct. 2011 I'm part of the Netweaver Cloud Portal Mobile team.
The NWCP is the fastest thing we ever delivered. It was POC'd only 14 month ago, the first line of UI code has been written 11 months ago, one thing led to the other, and it's out there right now. It's been an amazing journey, and it's only the beginning.
ohad.yassin, in his BIF link to me, introduced the following questions to me:
- Which UI technologies are used by cloud portal for what parts of the product?
- What were the reasons to move from Sencha touch?
Let's hit it.
Cloud Portal UI technologies:
- jQuery
We, as the rest of our civilization, are using jQuery as a DOM search and manipulation library. Our expectations here are clear; we don't look at it as a framework that will solve our complex architectural requirements, such as giving a full-blown object-oriented-programming implementation, or providing us with an client side MVC API's. We enjoy mostly as it abstracts from us the need to deal with the delicate cross-browser different, related usual to DOM related functionality. I must say, IMHO the siplicity of the library here is the key success factor. It help all of us (and especially the less expirienced developers) to up and run very fast, and deliver big chunks of new UI almost every month, which is basically how things work when you're a cloud citizen.
- Propitiatory implementation of Javascript, HTML5 and CSS3)
As most of us are developing the SAP Portal's protofolio (Enterprise Portal, Enterprise Workspaces, Workspaces on Demand, Hana Portal Services) for many years now, we have a lot of experience in implementation of Portal related functionality. The technology is rapidly evolving, UX patterns are changing drastically, but the core of our business remains: centralize entry for all content and activities required by the information worker to efficiently accomplish his business tasks.
With that being said, we have renovated a pure Javascript framework (100% server agnostic) that defines the data-models, views and corresponding interaction patterns of widgets, pages, navigation patterns and sites.
This layer, is mostly responsible for the cool WhatYouSeeIsWhatYouGet experience, which allow site authors to create, author, manage and publish content as it was the easiest task ever. For example, instead of defining titles for objects withing long, boring administration screens, one only needs to double click any title to rename it, and as the alternative for defining predefined layout (anyone said T-Layout?), the author only needs to drag and drop his widget around the canvas to re-size and arrange them until he is happy with the pixel-perfect layout.
- SAP UI Development Toolkit for HTML5
"SAP UI development toolkit for HTML5 (SAPUI5) is a cross-browser JavaScript library for building rich internet applications. "
Outside the Cloud Portal Site Studio, there are some administrative tasks that need to be taken care for: exposing the content that will be available for authors, configuring connection to EP system to allow consumption of legacy content at runtime, defining roles for IDP users and setting site theming and branding. SAPUI5 is perfect for rapid development of such views. The generic component model, well defined and documented API's, and an infinite shelf of UI controls already implemented make you feel more proud toward SAP UI technology. The most useful component for us was the table which allowed consistent and usable experience of creating, modifying and deleting the Portal design-time objects.
OpenSocial is a public specification that defines a component hosting environment (container) and a set of common application programming interfaces (APIs) for web-based applications. Initially it was designed for social network applications and was developed by Google along with MySpace and a number of other social networks. In more recent times it has become adopted as a general use runtime environment for allowing untrusted and partially trusted components from third parties to run in an existing web application. We have debated a lot weather or not we want to implement the open social gadget/container model; SAP Enterprise Portal, the older brother of NWCP, uses a more server-driven model of portal components and component container. The power-lift toward client technology, suggested us to rethink the whole component model concept. We found open social as a very structured, sophisticated yet simple specification, and we propose features to our customer's developers. features are basically a declarative API and it is being configured by the widget developer. A feature is saying that the widget assuming existence of some Javascript code in the context of the widget, and its container (site environment). The code is being injected at runtime by the opensocial server, and widgets can reuse valuable functionality such as pub-sub messaging (allowing widgets and container to interact at runtime), dynamic menu's API, views, persistence of preferences and personalization. The nicest part is that these API's are being consumed by Cloud Portal customers just the same as they are by us - Cloud Portal developers.
Additional reading about our API's
- Sencha Touch
About a year ago, one of my colleagues was asked to research some of the mobile-web development frameworks, as our Product managers decided to really go mobile first and implement our iPad client before we have a desktop-browser version. Some of us had really good experience with ExtJS, and we decided to kick-start with Sencha. The first few months thought us mainly that mobile browser is a new kind of a creature, especially if you use iFrames often. Around that time, the operation of Cloud Portal took one more step toward production, and another UI team joined the project to implement the desktop authoring experience. As I mentioned earlier, we have a lot of proprietary code and knowledge regarding portal UI implementation, and the desktop team did an excellent job. At that point, we wanted to make sure that we are not running with a double code line, one for the desktop (a proprietary implementation), and a parallel one for devices - based on Sencha Touch; we decided to try extending our desktop client so that same features, same experience and same code will serve desktop and mobile, authoring and consumption. It was not easy to say the least, but I can proudly tell you that when you swipe your fingers above a Cloud Portal client on a tablet, the cool navigation is the same code we use for desktop navigation, with a few more lines taking care for the mobile gestures.
So, I hope you enjoyed reading my first post here as much as I did authoring it, thanks Ohad for the chain. Feel free to post questions here, if you require more information about any of the topics I've mentioned above.
And now to the fun part
In the spirit of Blog It Forward, I would like to ask:
oleg.kossoy: as the first UI developer in the project, can you tell which technological problem was the most challenging?
ram.alon: as a product manager, how do you balance between stakeholders requirements, and the will to stay a generic portal platform?
See you next time,
Eran
- SAP Managed Tags:
2 Comments
