openSAP Experiences

(Please see the update from later the same day as I posted this, at the bottom.)

Don’t get me wrong, the openSAP initiative is excellent, free learning materials of high quality? Yes please and thank you! This instills a passion in me (and I’m sure many others) for (a) learning more and (b) trying to attain the highest achievement. In the case of openSAP, this means trying to attain high marks in the assignments.

Unfortunately, the question and answer sections of the weekly assignments sometimes get in the way of that, in that the questions and / or answers are ambiguous. The current openSAP course “Build Your Own SAP Fiori App in the Cloud“, has great content but the questions are dubious. Here are a couple of examples, that we’re discussing on Twitter right now:

In the assignment for Week 2, there is the following question, with the 4 possible answers thus:

Within the context of SAP HANA Cloud Platform, where do applications run?
(a) In the HANA Database
(b) Inside the cockpit
(c) In an SAP HANA Cloud Platform account
(d) On the SCN community page of SAP HANA Cloud Platform

The officially correct answer has been marked as (c). But an account is not somewhere where code can be run. It’s not an execution environment. It’s an accounting, configuration, billing artifact. It’s the credentials, the units of computing allocated and allowed, it’s the sets of permissions for access to features and subscriptions and so on. It’s not an execution environment. So there’s no way that anything can run in the SAP HCP account. The nearest correct answer as far as I could see is (a). But that’s not entirely accurate. However, the ambiguity of this question and the possible answers force me to choose “the nearest that makes sense” which is (a), as (c) can certainly not be correct.

Another example is in the assignment for Week 3, where there’s the following question and 4 possible answers:

Which end-to-end application development phases are currently supported by SAP Web IDE?
(a) Prototyping, developing, testing, deploying, and extending
(b) Requirements management, prototyping, developing, testing, deploying, and extending
(c) Prototyping, developing, functionality testing, A\B testing, deploying, and extending
(d) Developing, testing, deploying, and extending 

The officially correct answer has been marked as (d).

The official download materials for this week contain, as usual, a complete transcript of all the units, the slides, and the videos. This is great in itself. Unfortunately, the official transcript records exactly what the instructor said, which is (starting at 00:02:22, bold emphasis mine):

And we do so by covering the end-to-end application development lifecycle with one tool. And when we refer to the end-to-end application lifecycle development, we start from the prototyping of the application, then the development, the testing on the different devices of course, the packaging and the deployment into different application landscape and then later on after we released the application, also the extension of the application in order to customize it and make it suitable for the different scenarios and customers.

The slide related to this section looks like this:

Screenshot 2015-04-22 at 08.35.41

See that tiny couple of words in a footnote in the bottom left? They say “*future innovation”. The instructor didn’t mention this, so if you didn’t see the slide or were watching on your smartphone (which I was) where it was too small to see, but were nevertheless intensely listening to her, and then reading the transcript to double check the facts, you would not have noticed this.

Now call me old fashioned, but if the transcript says that prototyping is supported, then I take it that prototyping is supported. But I don’t just take the transcript’s word for it … I do prototyping in the SAP Web IDE. I don’t use the Powerpoint-based kit, I build simple views in XML either by hand in the coding editor, or sometimes with the layout editor. So practically speaking, the SAP Web IDE does support prototyping, regardless of what is or is not said.

The challenge is not the course itself, the content, as I said, is great. The challenge is setting clear questions with unambiguous answers. Here are two occasions (and there have been others, on other openSAP courses in the past) where this is not the case.

I’m passionate about learning and sharing knowledge, and being the best I can be. Something like this where incorrect answers are given as the officially correct answers, does make me somewhat sad.

But one thing’s for certain: If you’re reading this and not participating in the course, head on over there right now and catch up with these great learning opportunities!

Update 21:30 on the same day:

Now this is worth shouting about. Around 3 hours after I took part in the discussions on Twitter this morning and published this post, the regular weekly “Welcome to Week N” email arrived in my inbox as usual. But what was special was this section:

Weekly Assignments: Problematic Questions in Weeks 2 and 3
Week 2: Within the context of SAP HANA Cloud Platform, where do applications run?
Week 3: Which end-to-end application development phases are currently supported by SAP Web IDE?
In both these cases, we realized that the questions were slightly misleading. You can
find more information on the discussion forums for weeks 2 and 3. To ensure fairness toall our learners, we will assign full points for these questions to all learners who took the weekly assignments. Your scores will be adjusted at the end of the course.

This is the openSAP team directly and pretty much immediately addressing our concerns and worries, within a few hours. I cannot commend the openSAP team enough for this. Not primarily for addressing the issue (issues arise in all manner of contexts, that’s normal), but for being ultra responsive and in touch with the participants of the course directly.

Other MOOCs, heck, other educational institutions in general, please take note. The openSAP team shows how it’s done.

This Week in Fiori (2015-16)

Ariba UXGreetings! It’s time yet again to share a few newsworthy items that caught my eye this week in the world of Fiori. Let’s get to it!

Ariba Total User Experience by Ariba
We start out with something from earlier this month that just came to my attention via an article in SearchSAP – “Ariba unveils major overhaul of user interface“. At this month’s Ariba Live conference Ariba revealed their new “Total User Experience” approach to improving the user experience for their products. And it comes as no great surprise to see that it is — as SAP have been saying it would be — aligned with the SAP Fiori UX approach. Here’s a tweet from Tridip Chakraborthy:

You can clearly see the huge similarities in UX design and approach even from this one photo. The SearchSAP article states that “the Ariba UI does not share code with Fiori, but uses the same stylesheets, giving it a similar look and feel”. In a post based on my keynote at Mastering SAP Technologies conference earlier this year, titled “Can I build a Fiori app? Yes you can!“, I’d written:

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.

That abstraction is clearly in evidence here. I’d be really interested to see more details of how Ariba’s SAP Fiori UX “Total User Experience” looks under the hood, to discover how it ticks. It certainly looks great on the surface!

SAP Fiori Practitioners Forum by Katie Moser
Katie announced this back in January but I’ve only recently joined and I’m looking forward to getting involved and sharing best pratices with the other members. According to the post, this monthly forum is “designed to help you drive the successful deployment of SAP Fiori in your organisation”.

I understand that the sessions so far have been very useful. As we have all discovered already, Fiori is a multi faceted thing, and a place to discuss practicalities from design & configuration through rollout and beyond, with like minded individuals is a great idea. (Note that it’s sensibly only open to those that have installed Fiori).

SAP Fiori Theme for Kendo UI by Telerik
Screen Shot 2015-04-19 at 11.18.16Well not only do we have Ariba now embracing Fiori, but also a JavaScript UI framework by the name of Kendo UI. This framework is jQuery based, with AngularJS integration and support for Bootstrap and more. Unlike OpenUI5, which is the version of SAPUI5 (that powers SAP Fiori UX) that SAP open sourced, Kendo UI is software that comes in the form of a 30-day free trial, with a purchase required after that.

I watched the short video demo and it’s an interesting prospect. It’s not exactly the same, but pretty close. If you’re like me, one who has pored over the controls in UI5 for a long time, things are not quite the same, although from a distance you could almost be forgiven for mistaking it for “the real thing” (how that is defined is another story).

It’s worth bearing in mind that no amount of styling of controls will make an app into a Fiori app; while the styling is incredibly important and goes along way to helping the developer build Fiori apps, it’s just one pillar that supports the whole Fiori UX approach. The other pillars are responsiveness, design patterns and the other constraints and that are well described in the SAP Fiori Design Guidelines.

Well that’s just about it for this week. Until next time, share and enjoy!

This Week in Fiori (2015-15)

Screen Shot 2015-04-14 at 09.13.55Well hello there folks. This week sees the start (for me) of a week off on holiday, but not before I put out this latest episode of TWIF for a quick roundup of things that caught my eye in the world of Fiori. If you have any stories to share, let me know!

SAP Fiori Application Development in the Cloud by Monika Kaiser & Karl Kessler
The subtitle of this article in SAPinsider magazine is “Building, Deploying and Mobilizing Applications for Today’s Enterprises”. And as a great introduction, it certainly delivers on that. Not surprising given Karl’s pedigree in knowing about and writing about SAP technologies :-)

This is very much a getting started article, but where it scores is in the detailed and annotated set of screenshots that are useful for introducing folks to the whole process of building a Fiori app. Not generally, but specifically using SAP’s HANA Cloud tools, including the SAP HANA Cloud Platform, the SAP Web IDE and SAP Mobile Secure.

The article does remind me of the conversation I have with many developers at customers and partners as well as with individuals. It usually starts like this: “Q: Should I use SAP Web IDE as my main editor?” closely followed by “A: Well, it depends …”. There’s a mentality, or a mindset, amongst SAP developers that is hard to shake, because of decades of the same experience. As ABAP developers, we’ve been used to having to use SE38, SE80, SE24 and the like. Having the tool question pre-answered for us. And many of us have waited on SAP’s every word, even in the dark days when Eclipse was recommended as the development platform**. Now we have a choice, but many are looking to SAP for recommendations. And it makes some sense – SAP need to invest in building tools for the army of SAP programmers out there for many reasons. With the SAP Web IDE, they’ve landed with both feet on the ground, in that it’s not unpleasant to use and it comes with great productivity features that Just Work(tm). What’s more, no-one is saying that SAP Web IDE should be your only editor.

**yes, I know that SAP Web IDE is based upon Orion, but you’re not going to convince me that it’s the same thing

I use SAP Web IDE to start some projects off; I’ve even dabbled with the great plugin and templating system (see “SAP Fiori Rapid Prototyping: SAP Web IDE and Google Docs“), and the test offline version (see “SAP Web IDE Local Install – Up and Running“). But I don’t religiously stay with that as my main development environment … for that, I prefer a combination of a local NodeJS based server and the Atom editor right now. Mostly because a lot of the time I’m developing, I’m on the move, with little or no Internet access.

Today we’re in a very nice situation where there are tools from SAP available, and we can choose to use them as much or as little as we see fit. For me that’s a great improvement on earlier periods. Take a look at this article if you haven’t seen the SAP Web IDE yet, and you can make your own mind up.

SAP Web IDE: The Simple Way to Build and Extend SAPUI5 Applications by Yaad Oren
While we’re on the subject of the SAP Web IDE, here’s an opportunity to learn more about it specifically from one of the many great folks involved in its development and nurturing.

It’s an hour long video, and includes a presentation from an SAP Web IDE user, PepsiCo.

(I wish SAP would make these videos available on YouTube too – I manage 95% of my viewing activities there, with playlists and “watch later”, and can sit down in front of the TV to catch up. Please, SAP?)

User Experience sessions at SAPPHIRE NOW 2015 by Peter Spielvogel
I don’t normally talk much about Sapphire Now, I’m much more interested in SAP’s main annual event – SAP TechEd && d-code :-) But of course, without the business, SAP, primarily a software and platform company that just happens to write business applications**, would struggle to survive.

**yes, of course that was a troll, but I make no apologies for saying it

With huge emphasis on the User Experience (UX) you can expect plenty of sessions covering this topic and related topics too. The subtitle to Peter’s blog post is “SAP Screen Personas, Fiori UX, Design Services”. As you can imagine, being a conference focused on the business rather than the technology, on the surface rather than on the mechanics underneath the surface, you’re not going to find much in the way of the toolkit that *powers* Fiori – UI5. There are a total of 8 sessions that I could find, via the agenda builder, that mentioned SAPUI5. But that’s sort of the point. Much more important are the myriad sessions that Peter lists in his post, covering personalised user experiences with S/4HANA, SAP Screen Personas, SAP Fiori LaunchPad and more.

The UX topic is wide and varied, and while I will continue to loosely categorise SAP Fiori as a strategic approach and SAP Screen Personas as a tactical approach to UX, the fact is that with the LaunchPad becoming the new portal, and with businesses wanting access to more than what the current collection of SAP Fiori apps covers, there will be, for a long time, a hybrid solution to the overall user access and user experience to business data and processes.

What’s important is that we understand where SAP Screen Personas fits in, and with HTML5-based version 3 of the product (with JavaScript scripting support and more), just around the corner for all comers, we can easily imagine a cross-technology approach to all the tools required for a business user to carry out their responsibilities. With judicious use of theming and styling, we could move one step closer to that nirvana of a unified UX.

 

This Week in Fiori (2015-14)

Well hello again, this episode is brought to you from my woodstore at the bottom of the garden, where it’s actually warm enough to sit outside for the first time. The birdsong is prominent, I guess their user experience is improving with the ground softening and the worms and grubs becoming more accessible. Let’s go!

FIORI Notes 1 : One UX to Rule them All by Wilbert Sison
This week saw a simple post by Wilbert summarising a few of the key places to visit on one’s journey to Fiori enlightenment: The Fiori Cloud Edition Trial, the Fiori Apps Library and the UI5 Explored app within the SAPUI5 SDK (the more I ponder the name and the purpose and what it’s becoming, perhaps we should rename it from Explored to Explorer). What caught my eye with this post is that it was published in the ABAP Development section of the SAP Community Network, and it also gave rise to a short discussion on UI access to HANA.

First, the place the post was published. Fiori, and by direct inference UI5, is a cornerstone technology for SAP’s product landscape. What this means in practical terms is that we as SAP technicians need to embrace UI5 as much as we embraced dynpro technologies in the past. It’s that big. Having given a 3 day course on Fiori, UI5 and Gateway/OData last week, with my co-presenter Lindsay Stanger, to a collection of Web and ABAP developers (their own self-descriptions), it’s worth re-iterating the reality for many of us out there; many of us so-called ABAP developers. For me, the concept of an “ABAP developer” is somewhere between “meaningless” and “unneccessarily restricting”. Yes, there are developers out there that call themselves “<language> developers” or “<platform> developers”, and that is their perogative, but it’s an artificial constraint that is not helpful, and reminds me of “COBOL developer”. There will always be (in the forseeable future) demand for some COBOL skills, but is that the entirety of your outlook? If a mainframe dinosaur and ABAP developer like me can embrace UI5, so can you.

Then, there’s the question of UI, that came up in the comments to Wilbert’s post. It reminded me of a great Twitter thread initiated by John Moy where the frontend future for S/4 was discussed. I’ll leave it to you to enjoy reading that thread, but the takeaway for me was that people do understand that while wall-to-wall Fiori might be the vision, the reality will be different, particularly in the transition period while the Fiori app suites are constructed and made available. And for those of you pondering the earlier point about ABAP, and this one where SAPGUI and therefore dynpro is not going to disappear any time soon, think of COBOL again ;-)

April New App Distribution via SAP Fiori Apps Library
The SAP Fiori Apps Library is lots of things rolled into one. It’s a nice talking point and focus for the Fiori pundits, an example of a publically accessible Fiori App (where, being Web native, the frontend source code is available for perusing and learning from), and a good source of information on current Fiori apps. And I don’t mean just human readable information, but machine readable data too. I’d exhorted SAP back in August last year (in TWIF episode 2014-35) to make the data available, to supply “a machine readable dataset”. And that they have done, as of course the backend data source to the SAP Fiori Apps Library tool.

This of course is an OData source, from a HANA backend, and rich in information. Not only is it useful for powering the Fiori Apps Library app itself, but also for our own data-based analysis. You might have seen my post from earlier this year, where I showed you how to pull data from this very OData source into a spreadsheet:

Fiori App Data into a Spreadsheet? Challenge Accepted!

Thing is, while this data is valuable in and of itself, if you add a further dimension, time, it becomes perhaps even more valuable. What are the apps that are appearing over time, over the different waves? Are there any that are disappearing? Current total app count as of today is 541. Last month (an unscientifically and deliberately vague point in time, for now) it was 495. So that’s 46 new apps that have appeared (none disappeared, I also checked).

Screenshot 2015-04-05 at 13.46.17

I think it might be a worthwhile exercise to pull this app data on a regular basis, for comparisons over time. So as a starter, I have an experimental spreadsheet, Fiori Apps Data, with two snapshots, March and early April. I’ve added a few analysis tabs and one of the products is this breakdown of new apps by area, that I’ve titled “New Apps Distribution”.

Do you think this is useful? What other information can we work out with this new time dimension? How often do you think we should or could take a snapshot? Weekly? Daily? Could this be a community curated data set?

Answers on a postcard (or in the comments) please!

This Week in Fiori (2015-13)

Well, another week has gone by, which means it must be time for This Week in Fiori! The Fiori juggernaut continues to rumble on, and this week was no exception. Let’s get to it!

Build Your Own SAP Fiori App in the Cloud by openSAP
This week saw the start of the new free course at openSAP, which, according to the description, is all about “building your own SAP Fiori app that’s just as delightful and user-friendly as any of the hundreds SAP has built directly”.

This is great news, especially for those of us who had signed up to the earlier course “Introduction to SAP Fiori UX” but had been rather disappointed that it had had nothing much to do with Fiori UX, and more to do with deployment and setup. I wrote about this in TWIF episode 2014-40. A number of us did have a dialogue with the openSAP folks at the time, and I’m delighted to see our comments were taken on board – this new course looks to be what we have been waiting for.

So we’re into Week 1 of this new nine week course, and already in the last unit of Week 1 — Unit 5, Introduction to SAPUI5 and OData — we’re seeing JSON and XML on the slides, HTTP headers, and even a small glimpse at the superb UI5 toolkit, including a tiny controller and an XML View definition. This is more like it! Technical details on the slides.

Don’t get too excited, however. I spotted some errors in this unit that aren’t trivial. I’ve built courses before and I know how hard it is to get things consistent, but one thing you must do is be accurate. Here are some of the things I spotted:

“OData … is using SOAP and REST to communicate between systems”
OK, so first, REST isn’t a protocol, it’s an architectural style, so it is difficult to use a style to communicate between systems. But that is sort of forgivable, in that perhaps more accurately one could say that the OData protocol has RESTful tendencies. But SOAP? No. OData has nothing to do with SOAP, in fact, one could say that the OData protocol is orthogonal to SOAP.

“One of the most important libraries we have today is sap.ui.m”
I’m guessing that’s just a typo that found its way up through the layers to the actual presentation script. Because while there are libraries with the sap.ui prefix, there is no sap.ui.m. What the instructor is referring to is sap.m. The m originally stood for “mobile”, but now stands for “main”. The sap.m library is one of the main collections of responsive controls which are used to build Fiori apps. For more info, you might want to read “M is for ‘responsive’“.

“We have a library [sap.ui.table] for table, and that provides me with the ability to create a table that is very rich in data but also responsive”
For responsive tables, you probably want to look at the sap.m.Table control, rather than the sap.ui.table library, as the former is designed from the ground up to be responsive, whereas the latter is more for desktop apps.

MVC – View <-> Model data binding
In slide 13, there’s a classic MVC style diagram, but the data binding relationship between the view and the model seems to be shown as one way only:

Screenshot 2015-03-28 at 14.12.27

One of the many features of the powerful model mechanism and the data binding therein is that you can have two way binding. So I’d have drawn that arrow pointing both ways.

XML View definition
Being a stickler for accuracy (perhaps to the point of pedantry, of which I’m proud, not apologetic :-), this XML View definition on slide 14 is not quite accurate:

Screenshot 2015-03-28 at 14.15.27

The View is within the sap.ui.core.mvc namespace, not the sap.ui.core namespace, so the root element here should reflect that, like this:

<mvc:View xmlns:mvc=”sap.ui.core.mvc” …

Router? Bueller?
So if I’m going all out, I might as well mention that one thing that I think slide 16 could have benefitted from is mention of the Router in the architecture overview diagram. I do appreciate that these slides may have come from a time before the Router concept was properly established, but the Router is an incredibly important part of any Fiori app, so it would have really helped to see it here.

Screenshot 2015-03-28 at 14.21.38

That said, now you know, you can go and find out more about it! :-)

Don’t get me wrong, I’m very excited about this course, and these issues can be ironed out now they’ve been surfaced. I’m looking forward very much to Week 2.

Fiori Breakfast Event by Brenton O’Callaghan, Lindsay Stanger and me
On Tuesdsay morning this week in London, Brenton, Lindsay and I, along with other great Bluefin folks, ran a breakfast event all about Fiori. It was a really successful gathering, with business and technical attendees from SAP customer companies who were already, or were about to, or were just interested in embarking upon their Fiori journey. We had a special guest from one of our clients too, and to be honest, she stole the show :-)

It was clear from the event that people are realising that Fiori is not only here, it’s here to stay, and it’s a journey that is not just about new apps, but about a new SAP. If you’re reading this TWIF column, you already know that. It’s a genuinely exciting time for us as customers, partners and consultants, not only because of the UX aspect, but also because the present and future that is Fiori is based upon open technology standards that are right. SAP has grasped the nettle of user experience, and embraced the right tools and technologies. Good work!

Well that was rather a longer post than usual, so in the interests of keeping this to something you can read in a coffee break, I’ll leave it here, and wish you well. Until next time!

 

 

This Week in Fiori (2015-12)

Greetings! Last week saw the return of the This Week in Fiori series, with a video from me and Brenton. More on that video shortly. Before last week, the previous episode had been in October last year. So much has happened in the Fiori world that it would be crazy to try and cover it all. Instead, over the next week or two, I’ll pick out some items that stand out.

So let’s get started with some picks for this week.

Filtering Fiori Apps by Release by Gregor Brett
In last week’s video, we looked at the Fiori Apps Library app and found that it wasn’t easy to identify the latest apps. I mentioned that while the Fiori Apps Library app itself didn’t expose the information in that way, the data was actually available, and laid down a challenge for anyone to make the app do just that.

Screen Shot 2015-03-20 at 16.03.06Just a few days later the first response appeared – Gregor Brett came up with a nice solution, which was to patch the running Fiori Apps Library app, adding a new View Settings Filter Item to the filterItems aggregation of the actual View Settings Dialog used in the app. The items within that new View Settings Filter Item were bound to a data collection that was already being exposed by the backend in the OData service, namely the Releases_EV collection, which gave information on Fiori Wave numbers and dates.

Bingo! Nice work Gregor.

 

The Fiori Community by the SAP Community Network
Since the last episode of TWIF last year in October, SAP have created a new community within the SAP Community Network for Fiori. There’s already a community for SAPUI5, but now there’s a specific community for Fiori. I spoke about this in my keynote at Mastering SAP Technologies last month, and it’s an interesting and important distinction that SAP are making.

If you think about it, Fiori as an umbrella term is gigantic. It could be seen as a lot of things to a lot of people. Separating out the technical underpinnings (UI5) from other aspects (Fiori application configuration, extension and maintenance, UX design, deployment and platform subjects, and more) was only going to be a matter of time, if only to make the subjects more manageable.

But also remember that future Fiori offerings from SAP may not be powered by UI5. Of course, all of the Fiori offerings now and in the near future are, including all the S/4HANA applications such as the SFIN set, but when you consider SAP’s purchases – Ariba, Concur and SuccessFactors to name but three – a unified UX strategy is not going to happen from re-engineering the whole UI/UX layer of those (previously) third party products.

Visit the new SAP Fiori community and have a look around. It looks like it’s here to stay :-)

Planning the Fiori ABAP Frontend Server (FES) – Architecture Questions by Jochen Saterdag
Getting your Fiori apps served to the frontend involves making the following things available: the OData services, the Fiori Launchpad, the Fiori app code (views, controller logic, and so on) and of course the UI5 runtime. SAP has been slowly but surely socialising the term “frontend server” to refer to a system that fulfils this role. I first heard the term from SAP Labs folks in Israel back in 2013 (see “An Amazing 36 Hours at SAP Labs Israel“), and it’s becoming more pervasive these days. In modern parlance, perhaps, it’s now properly “become a thing”.

Of course, there are always considerations when planning such a server, and Jochen does a good job with this overview blog post. He answers some important questions, including whether you should use an existing PI system as the base for such a frontend server … the answer, clearly, is “no”.

10 tips to get you started on your Fiori development journey by me
Well, what’s the point of having your own blog post series if you can’t talk about your own content now and again? ;-) As I mentioned earlier, I spoke at the great Mastering SAP Technologies Conference in Feb this year. I wrote up my keynote into two blog posts, the second of which was a “top ten” style list. I’m sure there are many of you looking to embark upon this journey, so I thought I’d put together tips on what worked for me. If you’re interested in the first of the two posts, it’s “Can I build a Fiori app? Yes you can!“.

Well that’s about it for this week. See you next time!

The Maker’s Schedule, Restraint and Flow

A few years ago Paul Graham published a short essay “Maker’s Schedule, Manager’s Schedule“. It described succinctly how, and perhaps more importantly why calendar entry driven task scheduling, and in particular meetings, cause issues for makers. And I include myself and many of my colleagues within that “makers” general collective term.

Both the manager’s schedule and the maker’s schedule are important, but resonate differently and don’t mix. When making, building, creating things, solving problems, interruptions are disastrous, for all the reasons that Paul explains.

On the other side, time management, the proper organisation of tasks and working out what work to do, and how, doesn’t come for free. Managers and makers alike need skills in these areas. In order to build these skills, each one of us needs to understand that the areas actually exist, first of all. Email, phone calls, interruptions, the almost endless todo list and prioritisation issues are all things that we need to manage. And I recognise that I need to manage those things better. I use the Pomodoro Technique on occasion, but that’s just one tool. I also need to learn restraint. I need to resist the temptation to say “yes”, and to allow myself to be interrupted. If I get it right, I will find myself in flow more often. And that’s the mode that makers – developers, in our context – work.

Since that original article on the Maker’s Schedule, I’ve come across many other great articles and videos, and I wanted to share a few of them with you here, as you may find them useful too.

Remember – saying “no”, creating situations where you’re less able to be interrupted, using task and time management techniques that work for you, that let you produce more (or less, but that’s the subject for another post), is what we *should* be doing. Don’t fall into the trap of thinking that just because your project manager thinks and works in 1 hour chunks of time, you need to do as well. Of course, real life has a habit of getting in the way, but don’t let that stop us trying to be our best.

Further viewing & reading:

Scott Hanselman: It’s Not What You Read, It’s What You Ignore

Johnny Wu: Developer Productivity – The Art Of Saying “No”

Inbox Pause (great as an idea as well as this implementation)

The Pomodoro Technique

This Week In Fiori (2015-11)

Well hello again and welcome to TWIF readers old and new alike.

Last year I started the “This Week In Fiori” (TWIF) series looking at news, events and articles in the Fiori world. The last post (2014-43) was in October 2014, written by Brenton O’Callaghan.

The Fiori world is growing and spinning even faster, and Brenton and I decided it was time to pick up where we left off. To get the ball rolling, we recorded a half-hour session at the end of this week, looking at some news in the Fiori world. This time we took a more technical flavour, remembering that Fiori is UX, but built ultimately built with UI (see “Can I Build A Fiori App? Yes You Can!” for more on Fiori UX vs UI) – there are always two sides to any single coin.

If you have any news, or any suggestions for future TWIF episode topics, just let us know!

Here’s this week’s episode. Thanks Brenton!

Share & enjoy!

Why I’m Staying Close to UI5

I recently came across an article by Greg Donaldson – “Why We Are Staying Clear of SAPUI5“. Everyone is entitled to their opinions, and I do like challenges to assumptions and the status quo, so I enjoyed the article. I thought it would be worth responding with a similar piece, albeit with a slightly different title :-)

It would be an odd situation indeed for a unified consensus on any software, let alone software in this particular context – HTML5 development toolkits and frameworks, where, if you don’t have an opinion, you’re looked upon as an outsider. So I wanted to state before I start that there is no single correct answer, or even a single toolkit to rule them all, and Greg makes some important points.

I thought I’d look at the individual points that Greg made.

“Proprietary framework, no thanks.” 

As a lot of folks already know, UI5 is far from proprietary. It is written and maintained by web developers that work for an enterprise software behemoth, but the key difference is that UI5 has been open sourced, as well as using many open source libraries itself. In the article there’s the contrast made between “proprietary” and “industry standard” as though they’re opposites. This is not the case. So I’m not sure whether the criticism being levelled at UI5 is about its proprietary nature (which is not the case) or about (not) being an industry standard. This latter point is debatable: A toolkit powering frontend software across the entire ERP landscape for SAP customers feels like a de facto industry standard to me. Yes, not every company has adopted Fiori, but for one that drives its business on SAP products, UI5 is a likely software component.

I’m curious about the “SAP quirks” phrase which is also mentioned in this point. I’m not sure which quirks are being referred to, but if industrial strength design, MVC, internationalisation, automatic support for RTL languages, client and server side model support and an accomplished data binding system are SAP quirks, then yes please!

Further, AngularJS is mentioned as a framework with a huge community behind it. From what I can see, that community is fracturing, due to the major upheaval in (re)design between the 1.x and 2.x versions. That’s not to say that this couldn’t happen to UI5, but it’s actually happening right now with that framework.

“SAP Backend Upgrade?”

To do UI5-based apps “properly”, or “the SAP way”, then this is true; if you don’t already have a Gateway system in your ABAP stack landscape, then you’ll need one and also the UI2 add-in with which the UI5 runtime is supplied.

In my experience, however, it’s increasingly less common for an enterprise to not have a Gateway system somewhere; and with NetWeaver 7.40 you get the components built in as standard anyway. Further, installing Gateway components is often a coffee time activity.

But not wanting to over-trivialise this important original point, I wanted to point out the alternative; an alternative that is the most likely scenario anyway for a non-UI5 deployment such as AngularJS: a separate web server. You can just as easily host and serve your UI5 based applications, along with the UI5 runtime, from a web server of your choice. Then accessing the backend becomes the same task as if you’d chosen a different (non-UI5) framework.

And on the subject of accessing the backend, the point that was made about “remote enabled functions” does intrigue me. One of the advantages of UI5 is that it supports OData, an open standard, by the way, and one of the advantages of OData in turn is that it is a server-side model.

Calling remote function modules in this day and age is certainly possible and sometimes the only choice, but you’re not going to take advantage of server-side heavy lifting when it comes to data integration with your frontend. I’ve built Web-based apps with SAP remote function calls since the 90s, so I have the scars :-) Not only that, but the data abstraction model presented by the RFC approach is somewhat orthogonal to modern web based app data mechanisms.

“Browser Support”

This is of course always an interesting issue, but as an individual developer, and as a member of a development team, I prefer a solid statement about a well defined set of modern browsers which are supported by the toolkit I use, rather than have to do that job myself and deal with the vagaries that present themselves on a daily basis. Of course, rolling your own gives more flexibility, but it’s often more work.

And at least for the clients that I work at, the fact that (a) the browser choice is usually somewhat controlled anyway, and (b) the fact that in the BYOD context people even choose (choose!) to bring Windows phones, which are supported by UI5, underlines that choice for me.

“Frontend Developers Don’t Care”

At the risk of appearing obtuse, I’m going to absolutely disagree with this statement :-) Frontend developers *do* care; they care about the quality of the software they work with, about how and whether the toolkit they use does the job without getting in the way. Of course, this caring, this obsessive compulsion to be using the right framework and doing the right thing may mean that for some developers the choice is something other than UI5.

And that would be fine. There is no one piece of software that fits all requirements or circumstances, in any context. In the past I have used jQueryUI, JQTouch, AngularJS and other frameworks. And I would never rule them out for future projects. But right now, I’m investing time and effort in UI5, because it’s open source, it’s enterprise ready, it’s been designed & built and is maintained by committed, passionate designers and developers just like you and me (well, a lot more competent than me) and it is also fully in tune with SAP’s technology directions.

Skills in UI5 are going to be useful not only for building out the current and next generation of proper outside-in apps, but also for supporting the deployments, customisations and extensions for Fiori. A nice side effect at which one should not sniff.

 

Speaking at Mastering SAP Technologies

Next week I’m travelling to Johannesburg, to attend and speak at the Mastering SAP Technologies conference. It’s a great honour to have been invited, and I’m excited at the prospect of the topics covered in the agenda.

I’m continuing my journey spreading the word about Fiori and UI5. Last November I was in Sydney giving a locknote, a workshop and speaking at an executive lunch, at the SAP Architect & Developer Summit. A couple of weeks ago it was a short trip to Brussels to speak about OpenUI5 at FOSDEM, and now at Mastering SAP I have three slots. Here’s the description of each of them.

Keynote: Can I Build a Fiori App? Yes You Can!

Fiori is not just the new UX-focused, role-based application paradigm from SAP, it’s also a set of technical constraints coupled with a rich but finite set of design patterns for UI. Most importantly it’s made possible by certain parts of the SAPUI5 toolkit that were specifically built with Fiori in mind. (In fact, the first customers of the sap.m library in SAPUI5 were the SAP Fiori developers themselves). This session tells you what you need to know to build a Fiori app.

Tips & Tricks from the Trenches of a Fiori/UI5 Developer

Developing Fiori and UI5 apps with the UI5 toolkit is different than what you’re used to. Different generally because it’s HTML5 based, and different specifically because it’s UI5. Learn the tips and tricks that I use on a daily basis, and get to know how to drive, modify and extend Fiori/UI5 apps from the command line console of Chrome’s developer tools. Master UI5 debugging and maintenance from within the browser and get a step ahead.

Workshop: Building an SAP Fiori-like App From (Almost) Scratch – Hands On!

Starting from a skeleton app that has a structure but minimal content, and an OData or JSON data source, we build together a working Fiori app with SAPUI5. We cover bootstrapping the SAPUI5 toolkit, the Component-based approach to development, Model-View-Controller based development, XML views, navigation, data binding, model operations and more. This is similar to the Open Source Convention (OSCON) hands-on session I co-presented in Portland, June 2014, and the CD168 hands-on sessions I co-built & co-presented at SAP TechEd in 2013 (which were sold out / overbooked many times).

Perhaps I’ll see some of you there. In any case, share & enjoy!