Why I believe in the power of ASUG Influence Councils Part 2 – The ASUG UI Influence Council
As the title states, this is Part 2. Part 1 described the first ASUG Influence Council I participated in and can be readWhy I believe in the power of ASUG Influence Councils Part 1 .
This blog is about my experience being the customer lead for the ASUG SAP NetWeaver User Interface Council. This Influence Council (IC) first started at the end of 2008. That was about the time User Interfaces (UI’s) were starting to be used by more SAP end-users in promoting productivity. I was approached to see if an ASUG Influence Council could be started as issues with the current UI’s were surfacing and companies wanted a way to provide feedback to SAP. As an ASUG volunteer, I have access to see who has submitted abstracts for the ASUG Annual Conference. I found one that had been submitted by Yariv Zur so I contacted him. He thought an IC would be an excellent way to get customer feedback and agreed to become the SAP sponsor. Yariv would lead the java side and he brought in Thomas Jung to lead the ABAP side. We then got 9 other SAP Customer Companies involved and launched the UI Influence Council.
We started having regular conference calls/webexes. Our first goal was to set the scope of what would be covered in this IC. It soon became apparent that there would need to be more than one council as UI covers a lot of different technologies. It was decided to split into 2 councils. Our IC would cover the UI related tools and toolsets and another council would be formed to cover the Portal related issues.
We then narrowed the scope down to 13 UI tools/toolsets. I created a document that we used to prioritize and rate them. This document contained questions such as:
- Do you use this tool/toolset? (as not all tools were going to be used by each company in the IC)
- If not using it now, are there plans to use it in the future?
- If not, why not?
- If you do use it, what works and what doesn’t work?
- What would you lie to see improved?
Each company also rated the listed tools on how important they were so we could decide which ones to concentrate on first.
Once everyone had sent in their information, I compiled it all and this was the outcome:
- ABAP Web Dynpro
- Visual Composer
- .Net – UI Interoperability
- Java Web Dynpro
- WPC – Portal Webpage Composer
- Adobe Interactive Forms
- Business Client
- Flash Islands/Flex
- PDK – Portal Development Kit
- JSP
- Widgets
- FPM – Floor Plan Manager
- BOBJ – Xcelsius, Crystal, Voyager (those tools that interact with UI)
As 13 tools/toolsets would be too much to cover at one time, we chose to start with the top 5 for phase 1.
We then started meeting weekly and doing a “deep dive” per each of the top 5 issues listed above. During these discussions, other topics came up that were not necessarily considered issues, so, we created a section called “Strategic Concerns”. Some examples of these were:
- Improve Upgrade Paths of Technical Capabilites
- Dependence on Enterprise Portal (not all companies use the SAP Enterprise Portal)
- Browser Support
Examples of some of the information we provided to SAP in the Requirements Document for the top 5 issues were:
ABAP Web Dynpro
Very difficult to edit themes and change style sheets
- Need integrated styling tools for controlling the UI look and feel
- More freedom to apply style such as rounded corners, color gradients, etc.
- Have latest web features like placing the cursor will bring a small blob to display details
Option to develop stateless ABAP Web Dynpro
- End users are disconcerted when using SAP delivered WD and the browser Back button doesn’t work or causes unexpected results
Enable development of custom controls
- The SAP supplied controls may not meet the needs of individual company’s preferences
Enhance Events
- Currently, there is not a way to carry out an event on value help (F4)
Visual Composer
Migrating existing VC over to new/upgraded VC
- Allow power users to model their own dashboards using VC instead of Visio
Provide the ability to simplify the backend .api
- Have SAP provide off-the-shelf purpose built .api’s for consumption from VC
Limited UI controls
- Provide FrontPage HTML editor like functionality
Freestyle UI styling
Wide range of font size support
Creating a custom table to include set of controls with custom table layout
Limited styling options
- Need flexibility in controlling styles and themes independent of the portal themes
- Limited font sizes and color options
.Net – UI interoperability
Web Service Migration from ECC 5.0 to ECC 6.0 and SOA Manager
SSO between SAP and SharePoint web parts
Surface SAP BI data in MS User Interface
Ability to consume direct RFC’s from .Net instead of having to convert the service calls to ES explorer
JAVA Web Dynpro
Visual Styling Limitations (same as for ABAP Web Dynpro)
Difficult to find DC’s to include in linked libraries
- This is not just a web dynpro issue, but more of a java development issue
- Have SAP provide a cross reference so less time is spent looking for DC’s for a given SAP Class
Web Dynpro Flavor Parity
- Currently only available for ABAP Web Dynpro
Processing/Rendering Speed Limitations
- Performance has been improved in 7.2
Concurrent Development Complexities
Creation of Custom Controls
WPC – Portal Webpage Composer
WPC Authoring
- HTML based editors managing content
- Workflow based approval process of WPC content
WPC Usability
- Ability to clear multiple content spaces in layout
- WPC workbench too crowded
- Improve ease of use for WPC
Javascript
- Have option to not strip out Javascript when you go to run it
WPC Change Management
- Ability to check-in/check-out WPC content
- Version Management
Spell Check Capability within HTML Editor
Have an “undo” function within HTML Editor
Have the ability to expire content automatically
- Ability to expire content within the web page by a time period
All of this information was then compiled into a Requirements Document that was given to SAP. Each topic had the following information:
- Description of the issue
- A rating of Very High, High, or Medium (this rating was voted on by the whole council)
- Provided Additional Detailed Information
- Provided Business Case Examples – Providing business case examples is very important to SAP. They use this information to justify getting SAP resources to work on the issue.
Issues that were rated “Low” or had been described as “nice to have” were compiled into a separate document called “Additional Feedback Document” and was also given to SAP.
SAP then reviewed both of the documents given to them by the IC. After a period of time, they came back with a response. The IC found out that some of the issues were already being addressed. As Influence Councils are governed by NDA’s, we received advanced information and demo’s of new functionality.
This ended Phase 1 of the UI Influence Council.
The next goal of the IC was to put together a survey to gather information on what development technologies SAP customers are using. The results will be used to help put together best practises and UI usage information. The survey was fist sent out to members of the ASUG Technology Special Interest Groups. It was later then posted on SCN to gather information on a global scale.
One of the most interesting responses was:
It was now time to start Phase 2 of the Influence Council. We added some new members to the council and have started discussing the next 5 issues:
- Adobe Interactive Forms
- Business Client
- Flash Islands/Flex
- PDK – Portal Development Kit (collaborate with the ASUG Portal IC)
- JSP
We will also be collaborating with the ASUG SAP NetWeaver Portal Influence Council on some overlap areas. This Influence Council started in Q4 2009. They are focusing on providing input to SAP on selected areas in the next major release of the SAP NW Portal Product. One overlap area was the WPC. While this issue was an issue more related to the Portal, we included it in the Phase 1 of the UI IC as the Portal IC had not formed yet and it made the top 5 issues.
Additional issues have surfaced with the original top 5 toolsets, so, we will continue to gather requirements on those and provide this feedback to SAP.
To find out more on the status of Phase 2, there will be an Influence Council Update session at SAP TechEd 2010 in Las Vegas. For all of the ASUG related sessions at SAP TechED Las Vegas, check here.
Some examples of how the ASUG UI Influence Council has actually “influenced’ SAP are:
This IC identified theming as a weak point in Web Dynpro ABAP. SAP listened to this feedback, and, now, in 7.0.2, we can now theme flash islands and SAP will continue enhancing the stand alone theme editor.
One of the Strategic Concerns pertained to Improve Upgrade Paths of Technical Capabilities. One particular example the IC referred to was concerned migration paths for Upgrading Visual Composer. So, SAP provided information out on SDN to help address some of our concerns (link).
This webpage includes:
- What’s New in VC for SAP NetWeaver 7.2
- VC Migration Handbook
- How to transport Visual Composer content from VC 7.0 to VC 7.11 or 7.2
- VC Veterans Guide
The IC was also able to provide feedback to SAP regarding the UI information in Chapter 5 of SAP’s Guidelines for Best-Built Applications.
I feel very fortunate to have been able to participate in ASUG Influence Councils. If you ever get a chance to join one, I highly recommend it.
I've watched with interest some of your sessions on the ASUG UI Influence Council's report. And although I understand where the council is coming from, it sometime frustrates me to see the points raised.
Web Dynpro for example isn't the be-all, end-all presentation layer that the council would wish for, but then again, I don't think it was ever designed to be this. Sometime I think the council's wish-list/criticisms are a bit harsh.
For example, it is possible to catch the event of an F4 help within Web Dynpro ABAP (OK it's not obvious how to do this! But it is possible.) And the RIA Island for Flex and Silverlight mean that customers can extend the WD UI if they want to. (And do it in a way that won't cause multiple browser rendering issue - and is compatible with the business client).
Perhaps it is because I am at heart a developer and like technical responses to functional questions, but it has caused me anguish in the past (I've attended events where the Influence Council has presented) only to see one side of the argument and not the responses from SAP. Especially in the cases like above!
However! Thank you for your contribution - anything which leads to an improved user experience for the clients that I develop for, is going to be a good thing - and external views on this fed into SAP are great! I hope that one day we will see SAP's responses to the points raised.
"Web Dynpro for example isn't the be-all, end-all presentation layer that the council would wish for, but then again, I don't think it was ever designed to be this. Sometime I think the council's wish-list/criticisms are a bit harsh."
Don't you think it's reasonable for the council (and customers in general) to expect a be-all, end-all web-based presentation layer, though? It seems true that SAP placed constraints on what would be able to be achieved with Web DynPro when they designed it. Some of these constraints may have emerged from the architecture of the platform, but I think others were deliberate, in order to enforce a rigorous, standard method of development and resultant look-and-feel of the sort that SAP were used to with DynPro development on the backend.
It seems a lot of the council's requests/recommendations are in reaction to this sort of philosophy. The most fundamental requests (custom controls, better UI-skinning abilities, 2.0/Ajax-style immersion -- such as the "blob" request, closer integration with the browser environment to allow simple event capture -- like the F4 complaint) are essentially requests for fewer constraints, and closer access to the internals of the applications we develop with Web DynPro.
The overarching plea that I see is this: trust us a little more; give us a little more freedom. Don't make us wait for you to design the specific features that we need and deliver them to us in a form that is rigid and controlled. Instead, give us a more flexible toolset so that we can create those things ourselves in our developments. And I think that's reasonable. It might lead to less standardization than SAP is used to, but the alternative is worse: if too restricted, developers will be forced to move right out of the SAP development ecosystem and interact with it from a distance. If SAP's own UI technologies were not so restrictive, you wouldn't see developments like Nakisa occurring entirely off-system.
"And the RIA Island for Flex and Silverlight mean that customers can extend the WD UI if they want to. (And do it in a way that won't cause multiple browser rendering issue - and is compatible with the business client)."
Forcing developers to develop any truly custom controls/behaviours that they want in Flex or Silverlight is just silly. If SAP are going to do that, why not just let developers create custom controls? (I know you can embed chunks of HTML in the new CE versions of Web DynPro Java, but I get the impression that these are small, isolated islands of functionality that are tough to integrate with the rest of the application seamlessly -- though I'm open to correction there). It's also silly to assume that you can't ensure cross-browser compatibility in plain HTML -- everybody else seems to be able to. There's also no reason that we couldn't open up an API so that developers could _make_ their custom controls compatible with the business client.
I think the things the council are lobbying for are important (I know you do as well) and reasonable, and I think they also point to some fundamental flaws in the way SAP thought about this web framework when it was designed. Just my thoughts.
I think I agree with you, and disagree. I've replied (sort of) in a blog that should shortly be published.
I agree that we need more freedom, but I don't think that has to come from SAP tooling. If you want to build your own web pages with completely custom HTML, there's not a lot stopping you - SAP is very open to web service calls. Use your favourite tooling and develop away. The thing is, Web Dynpro isn't and, in my opinion, shouldn't be that sort of tool.
Islands _are_ well integrated and do allow extension of the WD UI set, and are the API for custom controls (business client or otherwise). But they are not really designed for completely implementing a UI.
It is interesting - we do have two different views - I think the UI Influence Council were "wrong" to ask WD to do things it wasn't designed to do, you think that there were flaws in designing a product to work the way WD does. We both agree that their are issues, but there is a reasonable divide in the two views! Perhaps I've been too insulated in an SAP environment for so long that I am starting to see SAP as always right? (I don't think this is the case.)
BSP allows you to code your own custom HTML and JavaScript and mix it right into the SAP rendered stuff. You can create a completely custom look, feel and functionality. Or you can try to interact with the SAP delivered functionality - the HTMLB libraries (early predecessors of much of the rendering you see in Web Dynpro today).
This had many of the advantages you described, but also had a whole host of problems. Rendering code that customers created could have technical conflicts with the SAP rendering code resulting in painful resolution of JavaScript incompatibilities post Support Package application. Applications didn't all have a common look - or more importantly a common way of doing things - like Value Help. Even SAP's applications from different areas had completely different UIs. There was no centralized configuration or personalization capabilities.
One of the things that we (and many other customers) asked SAP for was better centralized framework capabilities and more consistency in the UI. Other customers complained because the technical knowledge required to create BSP applications was too high. It meant the average ABAP developer needed to learn about HTML and JavaScript. Web Dynpro is largely SAP's solution to some of those requests.
Now keep in mind I'm not trying to say that everything SAP did with Web Dynpro is right. In fact I'm not really trying to inject any judgement at all. I'm just pointing out some history that had a direct impact on the design of Web Dynpro. Its important to remember the lessons and customer feedback from that era as well.
This is getting kind of fragmented now, as I replied to Chris on his own blog (Firing a WDA event on using a Search Help - how to do it, without an NDA). But thanks for your response here.
I think I'm sometimes overly critical of WDP -- my comparisons put it up against mature web frameworks in other languages, but you're right that it's subject to a different set of constraints.
You're exactly right that we need a uniform look-and-feel for SAP web applications, and Web DynPro goes some way to providing that. But I think its designers took uniformity to the extreme and ended up crippling the framework.
It would have been easy for SAP to include simple, enhanceable components (like value help, tables, even the roadmap pattern) in a more flexible framework that didn't insist that all visual components be completely SAP-delivered, or based on a rigid model of rendering (a model that takes obvious inspiration from classic DynPros -- which is a little scary).
This would have allowed customers to use the standard controls, using a standard, configurable look-and-feel and then enhance it where required. Non-uniform functionality is _definitely_ better than no functionality at all.
I also understand your point about the learning curve for ABAP developers. But was it really necessary to have ABAP developers write this code? In the early days (and, granted, they've moved a little further away from this now -- but are still officially firmly committed to the principle), SAP made a massive jump to web UI development in Java, as you know. That wasn't very successful. But it wasn't successful because of the way in which SAP adopted Java, because of the tools they developed to create WDJ applications, and because of the failings of the framework itself. Customers _did_ make the jump and hire Java developers to undertake those sorts of developments. And those Java developers were typically pretty comfortable with HTML, JavaScript, CSS and so on -- even though they weren't directly exposed to it in WDP.
Moving the focus back to WDA hasn't made customers any happier from a look-and-feel point of view, and it's doubtful it ever will: web applications developed by developers who don't know anything about web applications (and if you can't get a grip on HTML, JS and CSS, you don't really know much about web applications) are never going to be very good web applications, and code written at a distance like that is never going to be able to leverage the idiosyncrasies of the web platform effectively.
I know you weren't trying to inject any judgment -- and thanks for filling us in on some of the things that influenced SAP's design decisions. It's enlightening, and it makes sense. I might sound harsh and judgmental, but I'm not really trying to be. I do think that there needs to be more community discussion (or even criticism, if you'd prefer) around SAP's technical decisions -- this community is unusual in that there's kind of a dearth of it. That's why I think the council's work is so awesome, and that's why I tend to go on these tirades. 🙂
Thanks for the comments. I think it is important to get both good and bad feedback. I do not quite understand where you thought the councils criticisms were harsh? As, SAP has appreciated the honest and sometimes very blunt feedback the council has given them. And, they want more. One of the main values an ASUG Influence Council brings is that our issues/criticims are backed up with business case examples of why we would like something changed. Plus, it is not coming from just one customer, but many SAP customers.
As for the timeline of SAP's responses, well, sometimes they do not come as fast as we would like, but, it is still a good thing that they want to get our feedback.
Best Regards,
Karin
please don't get me wrong, I think the Job you (the UI Influence Council) did was fantastic! And it needed doing. It was just my personal view that you have perhaps gone down the wrong path with being quite technically focused rather than looking at the overall desire for a more flexible UI development environment. I've tried to elaborate in a weblog (will post a link when it's published.)
Please read a slightly fuller response, and some code for the geeks in my new post:
Firing a WDA event on using a Search Help - how to do it, without an NDA
Thanks,
Chris
Fantastic work is all I can say. Keep up the good work: This went really well and serves as an example for future initiatives!
Thank you and cheers,
Thorsten