SDK components – development direction & concepts
This is a blog based on comparison of approaches on how to get an Accordion… it is based on 3 blogs/documents on accordion in Design Studio.
- MANOJ KUMAR‘s post on Accordion Menu in SAP Design Studio
- Mike Howles‘s post on Design Studio SDK – SAPUI5 Accordion Menu
- Karol Kalisz‘s post on Design Studio SDK: (dynamic) Accordion Component
Here I would like to concentrate on the use cases and approaches. I list the points which
1) standard modification vs SDK
many complex controls can be produced by uise of standard content and adjustments via CSS, but my question is – how far should this acrually go. When looking at many posts, not only this example from Manoj (which is by respectable – the way seems to be very advanced and I am sure this was also time consuming), but also some other blogs on various modifications to get a requirement done I ask myself – is this often a requirement to stay on standard content? SDK is not so difficult, simple controls can be created easily – one day development and it is available. What is the reason that it is not followed on? Is there something we can help about from SAP side?
2) dynamic vs static
second point is – there is a nice option to create the advanced properties for SDK components, but what is the requirement of consultants – do you need more the way to definve the content by easy to use properties (very good example given by Michael in his accordion) or do you need something what is more dynamic in use (check out my accordion).
3) technical key vs text
I am coming from the development side, so I always work with technical name and keys (which I like to be unique), Michael has made the Accordion menu based on texts. Question here, how are you working – based on texts (how are you handling then translation) or is it ok to use keys for scripting access?
4) pre-defined vs re-loaded
I have placed the event “onFirstExpand” to allow load of the content when the section gets expanded, this is of course nice when you have bigger data to be processed, but in general – which direction are going your requirements for such components? more static creation and then no updates or dynamic load of content on user change?
5) woks-as-is vs styles
I have started to apply special styles to all content I create in the components, is it clear and usefull to all how this can be used? or you would like more “styled to the end” components which you do not need to touch any more in terms of Ux?
6) properties vs setters
In many cases the property can be made visible in the designer (independent on the place – properties or advanced properties) but the easiest way is to provide scripts, eg. in my Accordion you do not find any option to define the content, but you can make this with scripts. Is this something which is desturbing oyu in the work in designer (eg. the content in designer is always empty)
7) goodies vs basics
I have started to create components with images, which can be set optionally. This is a kind of goodie on top of the standard UI5 content, like in this Accordion case – is this something which can be used in your projects and helps you on the visualization or you would like more to stay on basics to be aligned with common Ux?
these are points of the non-tech nature which I would like to put for discussion. Perhaps this can help us to understand the reasons and use cases of all who are looking into Design Studio SDK.
Looking forward for your view on these topics.
Karol
Many ways to skin a cat for sure. Perhaps the 3 of us can start an accordion band! 🙂 Great post.
I also took your feedback and added the following BIAL methods to my component.
Karol,
I had some more time tonight to read your discussion points again and can give my opinions on a few:
Point 1 - At my company, very few other BI team members know HTML or JavaScript or CSS as they do not share the same web development background as we do. To say it is simple may be true for us who have web dev experience however there is a baseline in terms of support and maintenance that have to be thought about due to this "uncommon" skill set in our organization. I am a huge SDK advocate however these are some of the considerations that I have to remind myself of so finding a good balance of what works vs when it's time to go SDK is key for me.
Points 2 & 6 - I think having the ability to set most properties at design time is very important for the sake of designers for a true WYSIWYG experience. As you know and what I noted in my blog post also is that this takes work the write an advanced property sheet handler for the designer. I notice many times this code is much longer than even the component code itself and feels like a chore. Coming from an Xcelsius Flex SDK however, it has gotten a little better since we can JSON serialize complex properties with less effort. Bottom line is that I at least feel designer use is important second only to the end user experience so it's is a necessary chore.
Also related to designer experience, a true in-app CSS editor with realtime changes being reflected would go a long way to improve that experience. Surely this wouldn't be a huge undertaking given all the more complex functionality that has already been accomplished to-date. It can only get better from here!
I hope this input is helpful.
EDIT: spelling
My standpoint is as a relative new guy to web development as I was mostly in BW. So I will add some remarks as an outsider to the accordion band. I haven't got a response to all but some of the points
Point 1 : With SDK's I think you have to have a clear reason to do it. Personally I noticed that you kind of like to go to the SDK toolbox faster and faster as you can build anything fast. Problem is however that once you open the toolbox you will have an object that has to be maintained in the organization.
As you create more complex components
On point 6 personally I always create a function to create random data so that you have some kind of visualization to look at, even if you don't have data. As you're tweaking the layout it is so much easier when you can see what the object will approximately look like.
On point 7 I personally tend to go the 'goodie' road. Most of the time the reason to build is because the organization wants something looking extra nice.
for point 2 I noticed that there are a lot of small changes after the initial build. So now I tend to build in a lot of options to tweak it at design time.
best regards,
Jeroen
Hi Jeroen,
With Point 1 when you raise the issue of ongoing maintenance as a factor in steering away from SDK components, what are your thoughts about 3rd-party components? If an SDK component is developed by a customer in-house, or a consultant develops an SDK component exclusively for their client, then I would agree that the customer bears the burden of ongoing maintenance. However, what about SDK components developed by SAP partners for the general market? In this case, the continuing innovation and maintenance of such components is covered by the vendor and included in the licensing. In your experience, how have you found this to influence the decision to use SDK components?
Regards,
Mustafa.
Hi Karol,
This is going to make for some very interesting discussion. Here are my thoughts corresponding to each of your points:
1) standard modification vs SDK
I get the impression that there are two main drivers behind why complex content is produced with standard components instead of building equivalent SDK components:
i. There is a mandate at the customer for using only standard components, no matter what. Perhaps this is based on a perception that this approach keeps development simple but I think this can have the opposite effect. With complex content, when you attempt to create it with standard components only, there is a high risk that you end up with an unmaintainable spaghetti of script, CSS and components:
ii. As Mike has pointed out, in the traditional SAP development teams at customer sites the web skills (HTML/JavaScript etc) required for SDK component development are not always that common, so the fallback is to just use standard components.
In terms of what SAP can do to help:
a) Continue to provide example components with explanatory documentation that demonstrate particular techniques as you have already been doing with the UI5 components (such as data binding, array handling, method calls for example);
b) Continue to post Tips and Tricks blogs;
c) Continue to add features to the SDK to enhance component innovation opportunities. I see that DS 1.4 is introducing a Data Source SDK which is great. As I understand it, the ability to call ZTL functions directly from the component.js code is also a feature that is in the works. I think all of these types of SDK enhancements would help to encourage and support wider adoption of SDK components.
Also, the "standard modification vs SDK" topic raises a good question about SAP's position regarding 3rd-party SDK components. I think developing and maintaining professionally authored, enterprise grade components can become quite specialised and ideally suitable for development by partners. Does SAP want to encourage partners to develop SDK components? If so, what is SAP doing to help communicate the value proposition of partner developed SDK components to its customers? Looking at the List of Design Studio SDK Components I notice that there are not really that many 3rd-party (partner) components and wonder why this is so?
2) dynamic vs static
I think it's important to incorporate both aspects into a component as they address different purposes but in a complementary way. Script methods are necessary for dynamic manipulation and interactivity during run-time. The Advanced Property Sheet on the other hand provides a quick approach to setting up the main component structure with immediate visual feedback on the design canvas, which can then be further manipulated through scripting at run-time if necessary. A more sophisticated Advanced Property Sheet could also reduce the need for scripting by the application developer, especially if the feature for calling ZTL functions from the component.js code is introduced in the SDK;
3) technical key vs text
I prefer using the technical key for look-ups and filtering, and the text for display purposes. The technical key is particularly relevant when you have to pass the value for filtering a datasource/query for example;
4) pre-defined vs re-loaded
The use case depends on the situation. For example, the pre-defined (static) case is relevant for fixed user options such as certain menu items or filtering/configuration settings. On the other hand, the "re-loaded" option is particularly useful for databound components involving the need to drill through hierarchies as it would allow lazy loading of data;
5) woks-as-is vs styles
While a certain flexibility in customising styling is useful, in my opinion providing too many options can also be a distraction to the main purpose of the application. I have seen examples of very colourful designs with unique styles, which probably took considerable time to refine. However, I think for enterprise applications a simple and consistent approach is more appropriate. The SAP UX Strategy has set a very good example in this regard with the Fiori UI design. Given SAP's direction with Fiori and the tighter integration of Design Studio 1.4 with the Fiori Launchpad and Fiori applications, personally I think it makes more sense to adopt the Fiori style (Blue Crystal) when creating SDK components, for UX consistency. Even for customers that don't intend to implement the actual Fiori apps, I think the Fiori style is a good starting point for the visual appearance of SDK components;
6) properties vs setters
As per my comments for point 2 above. To elaborate a little further though, I do think it's important to provide some form of visual feedback at design time rather than just an empty frame. One approach could be to apply a placeholder image or sample content at design time;
7) goodies vs basics
While it's important to get the basics in place, I like to complement this with the "goodies" to enhance the user experience.
So those are my thoughts. Hopefully I haven't been too verbose 🙂 .
Regards,
Mustafa.
thank you all for the comments. I need some time to evaluate them...
in general,
I agree - we have different audiences - programmers and those who want to achieve the requirements without programming. I understand that for non-programmers also the BIAL scripting is challenging (as I have seen on questions in some other posts).
To all non-programmers - keep asking in case you cannot make a step forward, we will try to help you in the world of BIAL scripting!
Karol