An Opinion Blog: Floorplan Manager – A Compromised UI Solution from SAP?
I’ve been reviewing a lot of code lately; much of this based on changes to Floorplan Manager (FPM) applications or development of new Floorplan Manager apps. And do you know what I have not come across yet? I have not come across a Floorplan Manager app that I think is a good clean, simple design. Don’t get me wrong. Some of what I see is very good based on what is available, but when you think about software concepts like separation of concerns and variations of UI patterns like Model-View-Controller (MVC) – there seems to be one or two things that always stick out as limitations. It’s like your elegant design having a party and this small piece of bad design shows up uninvited…Awkward!
So there’s a lot of good in FPM, so let me highlight my theory about what was architected to be great:
- The ability to get a consistent style of interface, especially with Global User Interface Building Blocks (GUIBB’s).
- GUIBB’s providing the ability to create UI’s with small amount of code in a feeder class (which is mostly very similar each time); and some configuration.
- The whole FLUID editor (and the improved workbench in the latest releases)
- Reuse of UIBBs within a UI in different applications
- Plus lots more
The biggest feature though is the ability to provide configuration based enhancements/adaptions or personalisation capabilities for SAP developed content without modification and in many cases without even coding. And this is what I feel is the main point of FPM. To benefit customers, and not necessarily make life as easy as possible for developers (though it doesn’t go out of it’s way to not do this either).
Note – At my current customer, we saw the benefits and committed to FPM rather than straight Web Dynpro because we know it’s the future of Web Dynpro development (note I didn’t say future of UI development). After spending more time with it, and realising the above, we’re less certain this was the right approach for custom developments.
So where it becomes tainted is when you need to develop one of these from scratch. In essence, my concern is for all of SAP’s developers who are developing non-Fiori/BO/Mobile business suite applications with FPM and customers wanting to develop their own apps.
My issues are:
-
Poor examples of enterprise design being trained/highlighted.
-
Lack of consistency by SAP themselves in using it.
-
Reliance on singletons, highly structured wires, or events containing data that don’t provide any real controller to your application.
-
Lack of realisation within many consulting companies that FPM is not just Web Dynpro and that training is required.
-
The Fear Uncertainty Doubt (FUD) that goes with UI development and FPM causing simple UI’s to become very expensive.
Let me explain further below but first may I also say one thing that is really great is the FPM Developers Guidelines/Cookbook. It truly is a cookbook in terms of size. e.g. Imagine you have a large recipe book and you go and try eat all the recipes in one go – Futile right? I think I’ve gone back to the FPM Cookbook hundreds of times to get more recipes out of it. It is a great reference, but be warned, it will overwhelm most people if they try to learn FPM from the developer guidelines (which I tried to do initially).
Anyway, let me explain the issues and being a helpful consultant I’ll provide a recommendation to SAP/yourselves to get around this issue.
Please note: This all assumes you don’t want to move to HTML5/Gateway development for business applications just yet 😀
Issue #1: Poor examples of enterprise design being trained/highlighted.
A common bugbear I have with many training courses is when training goes as far as showing you how to do simple examples, but provides no information to you to do something in an enterprise way. Imagine learning all the HTML/JavaScript/CSS language and then being given a job at Google to build their next gmail web app. Realistically, there is a lot of work still required to get that job at Google, but at the very least if you did get that job somehow, there are some good enterprise like patterns out there to learn from and lots of example that put you in a good position to at least not get fired on the first day.
With FPM, the training appears to cover the basics from what I can tell but doesn’t get into design patterns per se. I didn’t get any response to my question specifically asking about this so can’t be certain:
The cookbook covers off aspects but no holistic view of how it should all hang together. So many options but “WHAT SHOULD I DO!?”!
Many examples on SCN look at single UIBB’s, or a screen with multiple UIBB’s talking to each other without application context. e.g. Very few examples of real applications.
Now I just noticed this book which has one section of the book which looks hopeful – Definitely something I’ll check out at TechEd next month:
Issue #1 Solution: TEAM FPM are doing a good job of trying to resolve this; and I think it’s the “recommended” end to end examples that are probably missing to really solve this issue. Ideally the end to end design should show a low-fi mockup of what is required and the thinking required to design the solution. Not an easy blog to write but would be very valuable to the SAP community. Note – There are a number of frameworks in place each requiring different thinking, but let’s just go for the simple scenarios first.
Another option is to buy that book and see if there are any answers there. If you’ve read it, would love to get your feedback, otherwise I’ll get back to you on that one.
Anyway, for now, checkout TEAM FPM blogs, and also look at the following wiki page (slightly dated now days but still has good info):
Note – Part of the issue is also to reinforce the underlying UX patterns that are required within the GAF/OIF/OVP’s since you’d be very surprised what some developers think is normal within a GAF going from Initial screen all the way through to Confirmation screen as an example. At the end of this blog you’ll see what I’m going to do in the end for simple apps which will probably become an anti-pattern but at least it will be easy to create and maintain the FPM app IMO.
Issue #2 Lack of consistency by SAP themselves in using it.
Have you ever worked on HR FPM apps? What about GRC apps? What about the EPM Model examples considered to be a good example of design. HR uses Singletons most the time (arghh!); I believe GRC uses a monster framework which makes FPM development very easy but makes understanding it all a nightmare. EPM is almost nice with it’s use of shared data but lack of application controller was my problem I saw with many examples there.
For reference, here’s where Sandra Thimme referenced the EPM models within the Netweaver stack as a good starting point for enterprise examples:
Plus link to EPM Model information she references:
Issue #2 Solution: Partly same as issue #1; though we do need to grasp all the different frameworks out there and preferably get them under control. GRC is becoming another HR or CRM with how much unique behaviour is being built into these frameworks.
Issue #3 Reliance on singletons, highly structured wires, or events containing data that don’t provide any real controller to your application.
All I want in a simple application pattern is a controller, a model and set of views. The views should be able to map to the required model/data via the controller. The view can fire events that reach the controller, but the controller effectively controls the overall behaviour beyond a view.
Now use of Singletons is reasonable within the controller (using the app controller within FPM), but do I then create Singletons for every View? Do I reuse singletons across different views even though they may not relate? How do I know what visibility the Singleton’s have. In essence, singletons are not the answer here unless we’re talking about one-off UI’s that are not reused. Yuck…
Wires seem to do the trick, but locks you into this list<->object style of interaction with specific coding also required. It’s also very behind the scenes to the application and a little out of control IMO which personally I don’t really like. Good thing about wires is the visibility given though directly in the FLUID editor. Note of warning – I’m very green when it comes to the usage of wires so probably have a lot to learn and maybe the above can all be solved easily.
Shared data – Well – This is probably my recommendation for larger apps and something worth exploring further as a good standard – though still a little hidden in terms of context unless you go searching the code.
Issue #3 Solution: Now this one requires development effort to the whole FPM framework. Extending the Application concept to similar to the context mapping in Web Dynpro would be fantastic so that visibility is easy. I’m guessing we’re not going to see a change here and have to live with one of the approaches above with hopefully at least some improvement in visibility within FLUID. Awkward!
Issue #4 Lack of realisation within many consulting companies that FPM is not just Web Dynpro and that training is required.
So as the System Integrator, you win a brand new greenfield implementation or upgrade project. Fantastic. Maybe it’s just ERP – Okay – We have ERP trained consultants – all good. Now unless you have a very strong technical director in your company – will they really know that things have ever so slightly(!) changed since Web Dynpro was introduced; and even if they do realise, do they have the power (& budget) to ensure that developers working within the UI space need training? My guess is rarely this is the case (at least in Australia where SAP training seems to cost more than in some other countries and developers typically need to know everything and cannot get all the training they need).
e.g. I remember early on my current project, people were looking at modifying the solution quite often not realising that configuration or enhancements in FPM were possible. Luckily we had a process to require approval to be given for modifications and implicit enhancements the current development lead and I had gone to the enhancing FPM apps session at TechEd last year to understand what was possible.
Issue #4 Solution: This is a common issue for SAP consultants across many areas, and realistically, it will come down (again) to the solution to the first issue since budgets for training are difficult to come by. Having one person officially trained, then doing internal training can be quite cost effective. At the very least, you can afford to buy the book I mentioned above!
The other point is for customers to check the credentials of customers, and ensure appropriately trained consultants are used. e.g. Asking for certification, while I personally don’t feel is that important, is one way of ensuring that a level of recent training has been undertaken. It also means that customers need to have the ability to review resumes and potentially interview their key developers.
Issue #5 The Fear Uncertainty Doubt (FUD) that goes with UI development and FPM causing simple UI’s to become very expensive.
There’s a theme going on with these issues. Lack of training and enterprise design examples are causing this. Simple Applications should take only a couple of days to build including documentation (but excluding stakeholder UI design/requirement sessions, reviews and approvals) for a experienced FPM developer who has a few Enterprise patterns up their sleeve already.
To bring home my point, get a developer to quote doing a simple ABAP report; then get them to quote on the same report in FPM. They should take around the same amount of time if they use the right GUIBB’s, and alternatively format the ABAP report nicely.
Issue #5 Solution: See above! In addition, to get things moving, see the end of this blog for my first step to resolve at least this aspect for simple applications.
Off-topic issue: One last issue slightly unrelated to FPM:
SAP: Please add the ability to save default variants to the search UIBB – It’s such a glaring omission from the UIBB and I get people incorrectly implementing POWL’s for reporting purposes just to provide this functionality!
What’s my next step for all of this?
Well, I’m obviously going to be asking a lot of questions and requesting a lot favours at TechEd next month in Vegas (Mentioned a few times now – Can you tell I’m excited?), but also, I’m challenging myself now to post within the next week or so, the first end to end design approach and pattern that is reasonably easy to build and maintain with limited bad code (FYI – The awkward part of my design includes statics). The development lead at my customer has implemented this pattern to help him (and myself) better learn FPM and it’s quite effective and reusable for the very simple requirements we had. I’ll post it as a document in order to get improvements made over time since I know there will be better ways to doing this.
What’s your next step for all of this?
If you’re SAP Product management for FPM – Please control the other developers outside your space in SAP by listening to their concerns and providing guidelines to them on how to do this consistently in order to get maximum benefits. No more rogue framewoks please. And how about publishing these guidelines on SCN so everyone can benefit?
If you’re a developer – push for training, buy the book (letting me know if it’s any good), keep reading SCN, record the FPM cookbook and play it over and over while you sleep. And let SAP know what needs improving and any ideas on idea place to improve the tools.
If you’re a customer – Ask your SI what they are doing to get on top of the new tools (not just FPM)? Review CV’s, especially when doing custom development. Build your own list of approved UI patterns based on the SAP patterns, and get user experience owned internally.
If you’re an SI – Train your people on the skills they need to do their job before they need it, or at least just in time – noting that they will need play time to come up with enterprise designs. At the very least, have a good development architect who you invest in who can train/mentor the team when required. Preferably make that person a director/senior manager/partner, and give them budget to train people on projects properly!
And for everyone – provide your feedback on your experiences below, whether you disagree on the above, what you love, what you hate, or what you plan to do in Vegas at TechEd outside of the conference (I’m always up for new ideas on what to do before TechEd too)! Have fun all and thanks for reading.
Update post SAP TechEd 2013
I should add to above that after speaking with the folks who build FPM at SAP TechEd, they informed me that saving of default variants is in the current release of NetWeaver (actually been there a couple of support packs I believe) – Huge win for the Search GUIBB! They also gave me more feedback/information that I need to consume but will provide a blog hopefully next month once I get past my Matt Harding’s Fiori Like Challenge – Let’s Ideate (e.g. Brainstorm)…(Part 2)
.
Nice post, a couple of initial comments:
I think there is a way for the search feeder class to populate a default saved search... Although that would be code rather than a simple user maintained flag. Certainly it is possible to default search values.
Whilst wires do have visibility that event handling does not in the configuration, it still requires coding to implement and is a lot harder than events. I would only ever recommend wire use where event handling needed to be processed in a specific order. One should also note that a uibb (guibb or freestyle) can only have one out port, thus the outgoing wire container must be generic enough to handle all uses cases. Most use of wires I've seen certainly isn't generic.perhaps an interface that would define what fpm events a uibb could raise/handle which could be seen from the configuration editor would be the answer.
Any data sharing approach which relies on global variables aka statics,shared memory,singletons, is likely to result in code which is going to do something strange and then be a bugger to debug. FPM events might not be very visible to the configuration framework, but they do allow for reasonably loosely coupled and testable code.
Again, Good post. I'll think on whether I have more comments later 🙂
Thanks Chris. Was looking for personalisation of the search rather than dynamic to replicate old variant personalisation in reporting - a real opportunity for usability there. The fact we have lots of POWL's for what are reports is just scary since it's butchering POWLs.
Wires - Yep - Something about them doesn't work for me. Maybe if there was an elegant example I could be turned around but when I looked at a big example and the limited outports allowed; it just looked limited.
I have a more detailed example I'd like to go over on a whiteboard about how to handle this; but for now; I agree also about the data sharing approach and liked your event driven data I reviewed today 🙂 though from a documentation perspective, there was no visibility of this event at all so is kind of hidden. If the FLUID could do introspection to show this information, then maybe everyone would be happy!
Look forward to more comments (or your own end to end blog)- you're far more experienced with this than me!
Cheers,
Matt
ps. My End to End example will include the candidate design/spec for you as well so you can see where I'm coming from for useful and easy to maintain documentation versus after the fact, what was done and not why specifications.
pps. While I'm at it, is it just me, or is there lots of FPM events with lots of implied logic that isn't clearly documented anyway? e.g. Hiding the Next button by using the FINAL Action event to go to the confirmation screen. At least this one is in the FPM Cookbook, but it's not really clear about exactly how it all works without reading it very specifically. There are plenty of others from what I can tell to. And for the life of me, I couldn't figure out how to make a class (not WDC) that implements the application interface used as the application controller define it's own action meaning I had to override standard FPM events for my application. Another awkward moment for me!
+1 for FLUID introspection, problem is horse already left the stable there, guess it could be an optional interface that a UIBB/feeder class could implement, but then given the problems you have getting people (myself included) to write documentation, anything optional is likely not to get implemented. (unless you could code a switch in to require it for all Z* WDA's 😈 )
Hear you about the hidden/implied FPM events, certainly find that I generally need to drill down into the code of a UIBB/GUIBB feeder class to figure out what can/can't be done. Which is reasonably frustrating.
Other things that aren't so clear - the event processing loop for searches and lists - due to order of processing it requires populating data in the handle event method rather than the get data method - madness!
Will have to try to understand why you'd want to implement anything that implements an application control that isn't a WDA component. Thought you should be able to raise a WDA event at any time you like, given that cl_fpm_factory=>get_instance( ) returns the current fpm instance wherever you are. Unless you're working with the rare case of multiple FPM instances?? Classic case of a singleton that had to be reworked and may break existing code!
I notice that according to the doco - wires are designed for use when you are using an object framework such as BOL. Maybe that's why they are such a pain in the a* to get working for a normal app. 😉
Oh on UI patterns 😈
Down with the GAF!
There are situations where a roadmap pattern makes sense. Generally where there is a strict order that multiple screen's worth of data must be entered. Actually, yep, I think that's the only use case.
The select/edit/review/confirm pattern prevalent in WDJ ESS amongst other applications is a bad UX pattern. It should be replaced, IMNSHO, in pretty much all cases with a two screen overview/edit/save&back pattern. The OVP is great for this.
So I'd also suggest that customers look out for consultants that have a passion for good UX as well as those that are keeping on top of the latest in WDA functionality 😀 . And I'd suggest constantly reviewing your list of best practice, it's quite possible that something better may have just been delivered.
Alternatively, bring on JavaScript/SAPUI5/Gateway/ICF programmers and let's have some really user friendly builds (and suffer the poor support team left behind 😉 )
I've got a couple of examples at my current customer where GAF is the only real way. Basically, it's where you create an item, review it, then you can never change it again once saved (hence the review step). Now while that's a bit crazy that you can't change it after you created it; and that should be fixed; without a review step, you could get a lot of incorrectly created data.
Not a big fan of GAF either, but it's one of the patterns to use where appropriate.
And in terms of HTML5 scenarios; well that takes you getting a customer and SI ready to do that but I'm all for it, though would like Gateway in place to provide a level of control rather than just opening up ICF nodes to developers to provide any framework they can think of for providing data. In other words, you probably need a Fiori deployment to kick off things as customers will tick off requirements for products much quicker than they would for internal custom development.
Cheers,
Matt
Gotta agree with you here Crhis: " bring on JavaScript/SAPUI5/Gateway/ICF programmers". I've been doing some html dev with Bootstrap lately talking to the backend with plain http services - so nice. Much nicer that ui5. ;-(
Hi Matt
I enjoyed your blog but as I only have limited experience with FPM (mainly OIF in NW7.01) I don't have a lot to add. I've mentally filed this info away for future reference.
However, one thing that really jumped out at me from your blog was the following line "incorrectly implementing POWL’s for reporting purposes" and your subsequent reply to Chris' comment "The fact we have lots of POWL's for what are reports is just scary since it's butchering POWLs". I'm just wondering if you could elaborate on that a bit more?
My (possibly naive) view on this is that operational reports are, more often than not, just worklists. In other words... Why would you want to report (list) operational data unless you want to do something (work) with it?
Though I've seen the search UIBB, I've not actually used it productively so I'm interested to know why it is better than a POWL for reporting.
Looking forward to your response.
Cheers
Glen
Hi Glen,
If you are referring to operational worklists, then POWL's are perfect for that but if you are after a dynamic query report, then POWL's are not fit for purpose. Or in other words, if the query is suitable to be cached, for the one user to call over and over, then you're all good.
This pretty much answers your second question to, as the search UIBB implies dynamic query results to display in a list.
Hope that is of some help and thanks for taking the time to comment.
Cheers,
Matt
Thanks Matt, but I'm still not sure I understand. It's an area that I'm interested in so please excuse me if I keep probing.
Is it simply a case of: if the data should not be cached then use search UIBB, else use POWL? What about shadow mode for POWLs where the data and selection criteria are not cached?
Do you have a concrete example of a "dynamic query report" that should be implemented as a search UIBB as opposed to a POWL?
(Cheeky suggestion, humbly offered: This might be a good topic for a whole new blog post if you think it's too off-topic for this one... and you have the spare time 😏 )
Regards
Glen
No dramas, but just remember these are all my opinions based on my experience and could be completely wrong 🙂
Ignoring that caveat, I would say your statement should be the other way around. e.g. If you have the need to read data (asynchronously) and cache it for end users, then use POWL, otherwise use standard FPM paradigms. i.e. POWL's should be a specific use-case with FPM filling the rest of your requirements.
Good example of a dynamic query report...How about something like search for expenses incurred between date A and date B from these users (fill in A, B and Users as required)...
And in terms of new topic; well if you're following all the news at SAP TechEd, they may lead you to believe that you should identify the process you want to build, then create a design thinking approach to developing a Fiori like SAPUI5 application through Gateway or HANA oData services, rather than using anything in the ABAP space directly; but realistically, FPM/POWL still has quite a lot of legs left on it in the Enterprise but the point being, the focus isn't really on FPM/POWL right now, so not sure how much discussion would be had. Besides, many I talk to just say they end up going back to Web Dynpro or making their own freestyle UIBB's rather than reuse because of the assumed complexity of GUIBB's.
Personally, I don't know what the answer is, but I have a strongly recommend not abusing POWL's with what I call dynamic query reports. e.g. Imagine searching for transports through a POWL as another example.
Anyway, better stop there. I do strongly recommend you write a blog yourself to voice your opinion as an option to if you have a strong opinion on how POWL's should be approached - I'll gladly comment on that. That said, I will blog about the reuse design we came up with for FPM to make apps quickly in the next month which should hopefully make FPM seem like a better option than POWL's for generic reports.
Cheers,
Matt
Hi Matt,
Imagine me stumbling across this blog so many months after you wrote it! I can't get into all these deep discussions about wires and GUIBBs - because I am stuck floundering with the wealth of information (Cookbooks! Tutorials! Videos!) and yet there is no simple answer to a simple question.
Admittedly, I am not a UI designer - we all know that. But as someone who has now dipped their toe into the ocean of FPM, all I really want is that one perfect simple shell, and there just does not appear to be one in sight. <sigh> I guess I need to go even deeper over my head. So my concerns about FPM are far simpler than yours and the other commenters - what ever happened to a simple change requiring only a simple solution.
Perhaps if I overcome this simple issue, I will be encouraged to delve deeper. As it stands right now, that doesn't look very likely.
Sue
Hi Sue,
I'm still well overdue with writing a follow-up blog to this one with more guiding information I received at the conference formally known as TechEd and can't see myself writing it in the near term (busy with DemoJam app and my Face Search blog series after that), but you could always go with SAPUI5 (only slightly in jest), which at least for very basic workflow approval screens and the like would be easy enough to get a patterned approach to, albeit requiring Gateway set-up, gateway services defined, and lots of security thinking put into it also!
Actually, for simple scenarios, the singleton model discussed above, is really straightforward to implement and once you've mastered the form UIBB; is really quick to do...
Good luck,
Matt
Hi Matt,
In another (more perfect) world, I would love going to SAPUI5 and even Fiori. I guess I will just hold my breath for the next blog in this series.
Cheers,
Sue