Fall is in the air. In the Netherlands the rain clouds gather, Halloween is coming up shortly and GA of Design Studio 1.4 is near. More and more news is coming in about what to expect in the new version of Design Studio. In this blog I will look at a couple of the mentioned enhancements and give my thoughts. What do I think it will mean, where would I use those enhancements? And What do I hope they include?
All I know of the new product version is based on the roadmap and the two excellent posts by Tammy Powlas. (I have added the links at the end).
Drag & Drop
Drag &Drop is more intuitive than the current button clicking in the navigation panel. So that is an improvement. Somehow I thought that it would mean that I could interact with a Crosstab Component and drag fields directly to the numbers. That would be the most intuitive way of navigation. But Dragging in the navigation panel is an improvement over the current way of clicking the field, checking the boxes and pressing apply.
Context menu + drilldown
In the current version we already can do a little RRI like behavior. Using the APPLICATION.openNewWindow method + adding parameters could take you a long way already. But now with the context menu you have the ability to create several jump to targets. Additionally there are a large number of navigation options available.
Currently if you want to create an analytical type app you had to include a lot of buttons.
This options seems to give you the means to grant a lot of possibilities to the user.
I do think however that you need to keep those button around for design reasons as not every user wants to work only from the right mouse button.
Figure 1: Source SAP
Actually I think this is added for reasons of popular demand.
I know I had to deal several times with situations where I added multiple checkboxes to Grid components and added script to make sure you showed a checkbox for each member in the dimension.
The SDK’s offered here on SCN were already a great help on that matter.
Global script functions (with parameter!)
In my current applications I already start with creating a separate panel where I store all the invisible buttons. So I am quite happy that there will be an official location for these kind of global functions. Especially when you have a lot of buttons where you want to highlight the button that was clicked you have a lot of repetitive code.
At a first glance I thought that practically you wouldn’t have too many advantages over the current practice of hiding buttons. If you would keep them neatly in a central panel you have almost the same. However now you can add a parameter to that function.
That means that you can create more identical code for each button. For highlighting buttons for example :
Var thisButton = “BUTTON_1”; GLOBALSCRIPT_1.run(thisButton);
(note this is fake code, don’t know yet how to use script with the global script)
In the Global script you then can do a more generic script where you highlight the button based on that parameter.
Ideally you want to go one step further. Instead of hardcoding the name of the button clicked you would like to use the keyword THIS. Where THIS refers to the button in which the script resides that is currently run.
So the code would then be GLOBALSCRIPT_1.run(this.name);
The advantage is that once you have one button set you can copy it without having to go into the script to change the hardcoded value.
At first I had an entire different idea what this meant. In larger organizations you have often some kind of standard design that has to be implemented across the organization. Standard header, footer. These kind of things. I imagined that you could use fragments at design time for the standard layout from which you would add your own development. If for example buttons were added to the header then every application would change accordingly. But that isn’t the case (although I would like this)
The actual thing also has its merits. What you can do is build are basically small applications that a User can pick and collect in his own application. So for example with Tiles you can think of 20 – 30 themes that could be interesting to managers and each manager can pick 6-8 on his own dashboard. As each tile can pass different filters to click-through reports you enable highly personalized dashboards.
It would be great if you could change the fragments based on the user. So user 1 is entitled to these 20 fragments and user 2 is authorized for 5 additional fragments. But that is wait and see I suppose.
Figure 3 : Source SAP
Real-time + near real time
There are a number of use cases where a (near) real time link is very handy. For example help desks that want to how many incidents are open. Or a factory how production is going at this very moment. The workaround was to create a SDK that collected the data via ODATA or WSDL and create a global variable that would hold the data. Another SDK component that ‘knew’ about the existence of that data could pick this up. The disadvantage was that all components that would work with this data had to be SDK components. So life is getting easier, that’s always nice J
Speaking of life being easier, DataSource SDK fits that category nicely. People that have seen SDK’s I developed know that I always added code for random data generation. The reason was that when you design application you want to see how it will look. A grey square with the mention “No data “ doesn’t really help you figuring out the best possible design. Now with a temporary CSV datasource or manual input (static datasource) you have more options to draw up initial prototypes without having the need to have a background system in place. Especially in project where others are developing the data model for the data you need something like this so you don’t have to wait until they can deliver preliminary results.
I do want to warn though that for production you want to be very careful about using these kind of datasources. The idea behind Design Studio is that data is managed in the backend to keep one version of the truth. Creative use of this option could end up hurting that principle.
Figure 4: Source SAP
So all in all a lot of imagining done based on my current understanding of the version 1.4. I hope that it works out the way I think it will and perhaps even a few pleasant surprises I didn’t think of. I am looking forward to the end of November to have a first go in the new version J
Roadmap : (you need to log in )
Tammy Powlas Blogs about the Roadmap :