SAC Story vs Applicatie (2/4): Applicatie Scenario's

Gebruik je SAP Analytics Cloud (SAC) in je organisatie en ben je benieuwd naar de verschillen tussen een Story en een Applicatie?

Deze blog is het vervolg op deel 1/4: Introductie en neemt je mee langs een aantal scenario's die je tijdens het ontwikkelen van een applicatie tegen gaat komen. 

Scenario 1: De lay-out - Denk er van tevoren over na!

Wanneer je met een story werkt, heb je geen keuze en moet je elke pagina zelf maken.
Een applicatie heeft een flexibele oplossing hiervoor: de Tab strip!

Een Tab strip is een framework waarin je standaarden kan opstellen, bijvoorbeeld een standaardpagina of een deel van een pagina. Er kunnen tabbladen worden toegevoegd die zich gedragen als een canvas waarop grafieken, tabellen of andere objecten worden toegevoegd, al deze objecten noem je in een application ‘widgets’.
Je kan zo veel tabbladen toevoegen als je zelf wilt, zelfs nieuwe Tab strips op een tabblad is mogelijk.
Hierdoor is het van belang om van tevoren na te denken over de lay-out van je pagina.

Het advies is als volgt:

• Gebruik een Panel om je header in te maken.

• Zet vervolgens je Tab strip hier direct onder.

• Maak je pagina’s binnen deze Tab strip zoals je ze ook in een Story zou maken.

Kortom: vooraf nadenken over de lay-out van je application bespaart je veel tijd. Met 1 header op een tactische plek en een Tab strip hoef je changes niet op elke pagina door te voeren.

Scenario 2: Naamgeving geeft structuur

In een applicatie krijgt elk object een technische naam waarnaar verwezen wordt in de codes. Een tabel krijgt standaard de naamgeving ‘Table_1’, daarna ‘Table_2’, ‘ Table_3’ en ga zo maar door. Dit werkt zo voor elk object.
Gelukkig kan je wel de naamgeving van objecten aanpassen om makkelijker te kunnen verwijzen.

Het geven van een passende naam voor een object kan lastig zijn. Deze blog kan je helpen!
Gebruik in het vervolg de volgende naamgeving om je objecten in je applicatie gemakkelijk terug te vinden: [Paginanaam]_[Objectnaam]_[Functionaliteit].

Hieronder twee voorbeelden: hoe wij het vaak zien gebeuren (rood) en hoe wij het adviseren (groen).

Scenario 3: Commentaar is van levensbelang

De subset van JavaScript die in een applicatie gebruikt wordt, biedt in principe niet veel ruimte om out-of-the-box te gaan.
Echter, wanneer je twee developers aan dezelfde functionaliteit laat werken, is de kans groot dat ze met verschillende oplossingen komen.
Hierdoor is een uniforme manier van ontwikkelen een must. Denk hierbij aan een standaard naamgeving voor de objecten en begeleidend commentaar bij elk stuk code.

Nu hoor ik je denken: ‘Begeleidend commentaar bij een stuk code? Dat doe ik altijd al!’.
Zodra er applicatie met spoed opgeleverd moet worden, wordt de stap om commentaar toe te voegen echter vaak overgeslagen met het oog op tijdswinst.
Voor een eerste oplevering is vanuit een tijdsoverweging nog te verantwoorden waarom er geen commentaar is toegevoegd. Maar stel je de volgende twee situaties voor:

• Developer A maakt een applicatie, maar heeft weinig commentaar toegevoegd. Er wordt een foutje ontdekt in de logica maar developer A is niet meer beschikbaar, dus developer B moet eerst uitzoeken hoe de applicatie werkt. Doordat er weinig commentaar is toegevoegd, kost het relatief veel tijd voor een kleine change. Hier is 3x meer tijd nodig om uit te zoeken wat het probleem is en waar het zich bevindt, dan het daadwerkelijk oplossen ervan.
  

• Developer C maakt een applicatieen heeft iets meer tijd genomen om commentaar toe te voegen. Hierdoor wordt het analyseren en vaststellen van het proleem een stuk makkelijker, waardoor de oplossing sneller geïmplementeerd kan worden.

Per iteratie dat er iets aangepast moet worden, neemt de tijdswinst van het toevoegen van commentaar toe.

Scenario 4: Pixels vs percentages

Doordat een applicatie pixel-perfect kan worden gemaakt, is hierin de kans op een ‘foutje’ groter dan in een story.
Elke widget kan tot op de pixel precies worden neergezet en daar waar je in een story geen objecten op elkaar kan zetten, kan dit in een applicatie wel.

Binnen een applicatie kan je in de Styling-panel voor elk object bepalen hoe groot het moet zijn en waar het precies moet komen. Dit kan worden gedaan door pixels, percentages en automatisch berekende groottes te gebruiken voor de breedte en de hoogte.

Er kunnen verschillende zaken worden ingesteld op pixels en percentages, met het automatisch berekende derde veld o.b.v. de ingevulde waardes:

• De breedte

  • Width - De breedte

  • Left (X) - De marge links van het object

  • Right - De marge rechts van het object

• De hoogte

  • Height – De hoogte

  • Top (Y) – De marge boven het object

  • Bottom – De marge onder het object

Hier is wat interpretatievrijheid, om bijvoorbeeld een object over de gehele breedte van het canvas te maken, kan je de volgende instellingen gebruiken. Hierin kunnen percentages en pixels door elkaar worden gebruikt:

• Width = Auto; Left (X) = 0px; Right = 0px

• Width = 100%, Left (X) = Auto; Right = 0%

• Width = 100%, Left (X) = 0px; Right = Auto

Doordat een application niet standaard responsive is, moeten deze pixels of percentages altijd handmatig worden ingesteld.
Het voordeel hiervan is dat objecten tot op de pixel precies neergezet kunnen worden, waardoor de uitwerking van een application vrijwel altijd dichter bij het ontwerp zit dan een story.
Het nadeel hiervan is dat het veel meer tijd kost om alles tot op de pixel precies neer te zetten.

Let’s Connect!

Wil je nog meer weten over SAP Analytics Cloud en hoe Business Intelligence jou kan helpen? Of zijn SAC Applications jouw toekomstige hobby en wil je het daar met ons even over hebben? Neem dan contact op met Roel van Bommel (06-226938392) of Kris van Brouwershaven (06-40269873)