10 tips to get you started on your Fiori

development journey
A developer's journey to a new set of technologies is a
very personal one, but there are definitely a few pointers
that I can give you based upon my own experience.
Following on from my previous post Can I build a Fiori app? Yes you can!
here's a top ten list of tips for the next steps on your journey to become a
Fiori developer.

1) Study the SAP Fiori design guidelines

Read the content of SAP Fiori Design Guidelines website. And then read it
again. Fiori apps are successful at a UX level because of the consistent
design that abounds.
The design didn't just happen by accident - Fiori apps don't look the way they
do for a random reason. They're not immediately recognisable by pure
chance. Everything, from the pixel-perfect precision of the design and the
space between the design, is deliberate. Get that under your skin.
Understand what the different application types are; know what a
master/detail pattern is and what it's used for; get to grips with patterns and
controls. Appreciate the use of filters, the placement of action buttons, and
the subtleties of responsive design. And remember: often, less is more.

2) Get to know the sap.m library in UI5

First, a factoid. The first real customers of the UI5 toolkit, and specifically the
sap.m library and the controls therein (sap.m is one of the many libraries
within the UI5 toolkit), were the internal teams of Fiori developers at SAP.
They'd been tasked with building the first few waves of Fiori apps, and
needed controls to satisfy the app designs. They needed visual building
blocks with which to construct clean and consistent apps.
The superstars on the UI5 team in Walldorf and elsewhere - the designers
and developers - built out the controls inside the sap.m library, specifically
with those Fiori developer teams in mind. Fiori is built with controls in the
sap.m library.
Yes, of course, there are other controls that are also utilised, such as those in
the sap.ui.layout library. And those are super important too (for an example,
see the Grid control in this post: UI5 features for building responsive Fiori
apps).

But the visible building blocks that are used to construct a Fiori app come
from the sap.m library. These days the "m" stands for "main"; originally it
stood for "mobile", as a reference to the responsive nature of these controls.
How do you go about getting to know sap.m library controls? Start with the
Explored app in the UI5 SDK; it's a super resource that gives you real
examples of how the controls can and should be used, and you can say
"show me the code" too.

3) Understand components and routing

These two concepts from the UI5 toolkit are essential for building non-trivial
apps properly. Arguably, you can build Fiori apps without these two concepts,
but you won't be able to include them in the Fiori Launchpad, and you won't
be able to navigate to them from other Fiori apps.
The Component concept is fairly straightfoward, but the implications are
subtle and wide-ranging. The essential mantra is "think local, not global". A
proper Fiori app should be self-contained, not refer to global mechanism such
as the UI5 runtime core and the central event bus. Each component has its
own event bus, as well as its own router and routing definitions.
If you examine the details of the app that accompanies the UI5 Application
Best Practices guide in the SDK, you'll find examples of how to build using
Components and routing.

4) Embrace MVC and declarative views

We've already come across MVC so I don't need to say too much there. So
what do you need to do? Learn how the structure of an app is built, using
screen-sized and invisible controls, and how the views within that structure
are related to each other and to their controllers.
And love it or loathe it, XML is in your future. All standard SAP Fiori apps have
their views defined declaratively in XML. And you'll quickly find out why - it's
the most concise, efficient and clean way to do it. Not a fan of XML? Get over
it.

5) Start using the WebIDE

Everyone will have their favourite editor, their favourite development
environment in which they're most productive and where they can
comfortably build Fiori apps. Sublime Text, vim, WebStorm, Atom, even (for
the masochists) Eclipse!
SAP's WebIDE might not be that favourite environment. But it's got a lot of
things going for it, and you don't have to make it your *main* environment.
Use the WebIDE to kick start your Fiori development journey. Extract and
examine the reference apps, which have been placed there by the folks in
the Fiori Implementation Experience (FIX) team.

Begin developing a new Fiori app from one of the starter templates, or even
starting from one of the reference apps. A Fiori app has a lot of moving parts;
if you're just starting out, getting help getting those moving parts going and
working well together is worth a lot.

6) Set up your local development environment now

If you've developed in the past within the soft padded walls of an ABAP
stack, you've had everything done for you. Or done to you, depending on
your perspective. You didn't have to think about your editor, about version
control, about syntax highlighting and linting, or even about serving your app
up for testing.
That was (and remains) the old world. Developing apps for the web is new.
This is not some inside-out based development where you create your UIs
inside of an ABAP stack and then push them out to be rendered in the target
browser. This is grown-up outside-in development where you're developing
directly for the new runtime - the browser.
There are plenty of guides showing how you can set your own development
environment up and get your development workflow going. Find one that
suits you and get going with it as soon as you can.

7) Make Northwind your new friend

Northwind is the well-known reference OData service that's out there and
available. This tip is not necessarily about the Northwind OData service per
se; it's more about making yourself (a) familiar with OData and how it works,
and (b) doing that in a way that's independent of any backend SAP system.
In light of this, getting to know the Mock Data Server mechanism, which is
also part of the UI5 toolkit, is also essential.
Yes of course you're going to want to build Fiori apps that consume data from
an SAP backend, and that also means OData. But that can sometimes be
quite an expensive goal in the early days; it might be that the OData service
isn't ready, or you haven't got access to it, or you're just on a train trying to
get something done in your local development environment and can't get
connected to that backend OData service. You can accelerate your journey
along the Fiori development learning curve by being independent of any
specific backend system. By being self-contained.

8) Learn how to wield Chrome Developer Tools &

the UI5 Support Tool
Building ABAP based solutions, you'll know that the debugger is a powerful
ally. The Chrome Developer Tools, along with the UI5 Support Tool are the
equivalent, and more, in this new world.

You're using Chrome, right? That pretty much goes without saying; it's just as
if not more important than your editor; in fact, it is *becoming* the editor.

The UI5 support tool

Get to know how to wield the superb development, debugging and tracing
features of the Chrome Developer Tools; understand what the UI5 Support
Tool can offer you. If you do nothing else today, hit Ctrl-Alt-Shift-S on a
running Fiori app and have a look at the Control Tree panel.

9) Master data binding

Data binding is where the frontend meets the backend. Master it. Understand
the nuances of object, property and aggregation bindings; learn the
subtleties and features of complex embedded binding syntax, how to specify
sorting, filtering, grouping, formatting and factory functions.

A lot of what you might think is achieved through imperative code in

controllers is in fact achieved through declarative binding. Don't be scared of
it, it wants to be your friend. One thing I'll say here, which is only partly true
but something that will help you as you bear it in mind: If you find yourself
making explicit OData calls exclusively, it is possibly a bad code smell. Not
all the time, but there's a chance.

10) Study existing Fiori apps

This tip of course is possibly the most important, and the most generic. If you
want to learn, improve your skills in, or eventually master something, the
one thing you cannot afford to avoid is reading. Looking at existing examples
of what you're trying to learn to build. Understand how to get at the nonminified sources of standard SAP Fiori apps. Look at the templates and the
reference apps in the WebIDE.
Make your breaks work for you by poring over other people's code while you
pour the hot water over your ground coffee. And yes, not everything you
read will be great examples of the Fiori app art. Remember that the folks who
wrote the Fiori apps are just like you and me; they've just had a bit of a head
start, that's all. It won't all be gold standard code. But even the bad code is
useful to read; find patterns and anti-patterns and learn from those.

Conclusion
Of course, if you ask others how you go about learning to build Fiori apps, it's
likely that they'll have other tips too. But I'm pretty sure that these will be
the common denominators. And they're all things that have helped me on
my journey. Happy travels!

Can I build a Fiori app? Yes you can

This started out as an essay as preparation for my
keynote at Mastering SAP Technologies in Johannesburg,
Feb 2015. I've split it out into two parts, the second of
which will give you 10 tips to get you started on your Fiori
development journey
In Feb 2015 The Eventful Group ran a great conference in Johannesburg Mastering SAP Technologies. I was honoured to have been invited as a
speaker, and I gave a keynote on the first day; the keynote was one of three
items I was contributing to the agenda.

The philosophy of Fiori

The title of this piece is in two parts. If we're not careful it could be a very
short piece, because I've already given you the answer in the second part "Yes!". What else do you need to know?
Well, let's start with some assumptions. I'm going to assume that, at least to
a greater or lesser extent, you're possibly a developer, or at least are of a
technical nature ... otherwise, you may want to stop reading now ;-). And
that you're wondering about Fiori. What it is, how it works, what the
component parts are, and how you put a Fiori app together.
You might be faced with the exciting yet terrifying prospect of building one
from scratch; you might be more in the game of modifying and extending
existing standard SAP Fiori apps. And you'd be in a good place; Fiori is a huge
part, some might argue the single most important part, of SAP's frontend
future.

Some definitions
In order to work out why the answer to the question is "yes", let's back up a
bit and start with a few definitions. Let's have a look at what Fiori means,
what it represents.

Philosophy

VA01, with the kitchen sink. Not Fiori

It's a philosophy. It's a novel approach to work where the focus is not on a
thousand features, the focus is on a particular undertaking that a business
person, wearing a particular hat, needs to complete. It's about moving from a
transaction oriented view of work to a role and task oriented view. Perhaps
you've seen the 1-1-3 concept in early Fiori documentation - one user, one
use case, three screens.

User experience
It's user experience. UX, as the hip designer kids say these days. This is
pretty closely related to the 1-1-3 concept. Three screens. What do those
screens look like? It's not about the colours, but it *is* about what a user
sees, and perhaps just importantly what a user doesn't see. It's also about
how a user navigates through the task at hand, and also how they become

familiar with visual paradigms so that when they move from one task, say,
approving a purchase order, to another, such as managing a product, things
are familiar, and they know what to expect.

PO approval, Fiori reference app

Manage product, Fiori reference app.

Cross platform
It's cross platform. And that means written for the One True Platform, i.e. the
web. Web native. So it runs on different devices, with varying screen sizes.
Desktops, tablets, smartphones. Even Windows phones! If that's not cross
platform, then I don't know what is.
So I've got this far and our conclusion must be that Fiori is actually a state of
mind

The distinction between UX and UI

But that's partly the point. I used the phrase UX, and specifically UX. Not UI.
There's a distinct difference between the general notions of user experience,

and how that user experience is realised. At some stage, in every computing
context, you're going to have to come down to bare metal.

And in our case, that bare metal is at the UI layer. There's also the data layer,
don't worry, I haven't forgotten about that. But let's just concentrate on the
frontend for now.
Have you noticed the subtle distinctions that SAP are making with regards to
Fiori UX and UI? I outlined that distinction in a blog post around this time last
year: The essentials: SAPUI5, OpenUI5 and Fiori. Now SAP are underlining
that distinction by creating a brand new community in the SAP Community
Network, specifically for Fiori. There's already a community for UI5, but now
there's a separate community for Fiori. And that's sort of the the point I'm
trying to make.
Before we get down to UI5, let's just consider this abstraction we know and
already have started to love, called Fiori. It could be realised with all sorts of
different technologies. If you think about it, that abstraction, that distinction
between philosophy and practicality, is the one way SAP can continue to
forge ahead with some sort of (eventually) unifying user experience strategy
while at the same time dealing with the reality of products from differing
sources, with differing frontends - Concur, Ariba, Lumira, and more.
Don't hold your breath, they haven't even managed to get login working
properly and cleanly on their service portal even after more than a decade ;-)
But the thought and the focus and the intention is very much there.

Getting down to it
So Fiori is technology agnostic, and deliberately so. But at some point you're
going to want to actually build something, so let's start to descend through
the clouds down to reality.

UI5 features
Well, full support for Model-View-Controller, for a start. Fiori apps can be
complex beasts, and adopting an MVC approach to your code design is
almost a must, if you want to survive with your hair intact.
And then there's a very accomplished data model mechanism for client and
server side models, with a rather powerful binding system.
Need to write apps that work in different languages, some of them right-toleft? Got that covered. Need to make your apps extensible? Yep, got that
covered. Need to build your views declaratively? Yep. Want to construct your

complex designs in a componentised way, with routing in between? Yep. You

get the picture.
And have I mentioned JavaScript? Well of course not, it almost goes without
saying. JavaScript is the water that flows through the channels in the
browser; for many, it's the new assembler, the new ultimate compilation
target. And UI5 is a JavaScript toolkit.

JavaScript
There's a lot of navel gazing out there right now about web toolkits and
frameworks not being "native" enough, not being JavaScript-y enough.
Frankly, I don't understand that. The whole point of a framework, of a toolkit,
is to make you more productive. And to do that by providing abstractions and
mechanisms that allow you to get things done, to build responsive user
interfaces and interact with data in backend systems, while not tripping you
up or getting in your way.
So to build with UI5 is to build using JavaScript, but it's not the full story. It's
understanding and properly wielding MVC. It's understanding how to build
applications where your application logic is separated from your view
definitions. And it's understanding where the joins are. It's also
understanding how to build an application that allows a user to get on with
the task in hand. They have a role, they have a task to perform, and they
want to carry it out with as little fuss as possible.
But it's also understanding where the data comes from, and where the
frontend meets the backend.

OData
And that's where OData comes in. OData is a protocol and a format. Folks
like to say that OData came from Microsoft, but the truth is actually a lot
more interesting. It came from RSS, or rather, from the broken community
that was borne out of a specific person trying to own the space (and failing).