Random Ramblings from a Developer – What is Mobile?
A couple of months back, I started a bit of a blogging journey with this post. As I could have predicted at the time, it has taken me much longer to find space in my schedule to carry on with the initiative and get the next part published but here it, finally, is…
What is Mobile?
The question of just what is mobile crops up a lot. In recent years, arguably due to the revolution kick-started by the iPhone, mobile has become a bigger than ever focus for both enterprise and consumers alike. Many would argue the consumerisation of IT has been driven in the main part by the massive uptake of personal smart mobile devices. I would add that mobile, as a vague definition, appears to be driving more uptake of IT solutions in areas of organisations that before wouldn’t have considered IT based solutions for their day-to-day challenges. But does simply having an app in the app store qualify as mobile? I’m not so sure…
How long is a piece of string?
Trying to define what mobile is can lead to numerous differing answers (some mostly-right, some mostly-wrong, all mostly-valid.) Getting a global consensus and agreement on any definition is probably akin to herding cats. As with many subjects, it comes down to perspective, context and opinion. So, I thought I’d share mine here in this blog post (you can decide for yourselves if it is mostly-right or wrong.)
Evolution vs. revolution
Some time ago, not long before SAP acquired Sybase, I had the pleasure of doing some internal work at Atos with some of the Sybase technical and pre-sales team. One of their guys, who had been in the industry for a long time, had an interesting take on where Sybase had come from with their definition of mobile. His view was that their unwired platform and approach to on/off-line, synchronisation and data management was equally applicable to someone sat at a desktop in an office connected to a LAN, as it was for someone out on the road using an iPhone via 3G or similar. The channel of access was almost superfluous to the design. It was a perspective that largely passed me by for some time…
With hindsight, I now have more of an affinity with where he was coming from. I was blinkered to a single and specific definition of what mobile means and how it can be implemented. I think many in the industry and beyond still share this relatively blinkered definition of just what mobile is. To some extent, we’ve been brainwashed by the power of Apple’s very clever marketing strategy and now, if you ask Joe Bloggs on the street for their definition of mobile, “app’s on an iPhone” would probably feature pretty highly (if you are lucky, you may get an Android proponent but still pretty similar answers.)
There are two sides to this – the first as already mentioned is testament to the ability of Apple’s very clever approach to marketing, branding and sticking to their own message. The other side of this brings me back to the consumerisation of IT. Not too long ago a smart phone was something that could take photographs as well as calls and texts – these days the functionality has moved on in leaps and bounds and the current smart phones are essentially mini super-computers, with a whole host of other hardware & features bolted on. They have become an embedded part of daily life for so many (although its important to say, not for all) and in many cultures & countries are now all-pervading. Although having said that, do many people do much more than call, text and take selfies?!
Mobile First…
In the web design/development world, mobile first and responsive design are big things. Following the explosion of smart phones and subsequently tablets, effort to make web-apps and websites responsive in their design and build appears paramount to the process of releasing new content and solutions. I have been doing SAP development for a good few years and I have to ask what is new about this? Ensuring the design and functionality of any page/application works on various screen sizes & resolutions is not anything new – it has always been a pain! Just search on SCN for questions in the ABAP forums relating to table controls and dynpro programming for example and you will see it isn’t just web that has suffered with this. Ultimately, fitting the solution onto a screen is a problem that is as old as the first UI.
I actually find the whole mobile first approach a bit odd. It’s almost like positive discrimination in the technology world. I kind of file it into the same bin as “Big Data” and “Cloud”. (And yes, I’m making the sarcastic speechmarks in the air as I type this.) We seem to work in an industry that is very, very good at re-inventing the wheel and giving it a shiney new 2.0 name – worse still most of us are very, very good at falling for it. π This is by no means a criticism – it is in part what keeps many of us in work, doing jobs that we find challenging, interesting & rewarding and working with customers who share the same ethos.
… What about Solution first?
I would argue there should only be one real approach to building stuff – solution first. That is to say, all that matters is that the solution works for the customer(s)/user(s) and deploys the correct technology/design approach/build methodology as is appropriate. I suspect the Design Thinking approach probably helps you focus on this solution first mentality. Stating an application must be mobile first just feels like you are excluding a whole range of possibilities before you have even started. Just as starting with a desktop only solution probably means you’ll have extra work to do at a later date if/when you do go mobile. This is of course where the responsive approach comes in but it is so often directly associated with mobile first, they are in danger of becoming one and the same entity.
Search via Google for mobile first and you will find countless resources, opinions (hopefully this will soon be one of them) and competing perspectives. So many articles claiming mobile first is right or mobile first is wrong. I just cannot help feeling the war is being fought at the wrong level – mobile vs desktop is just too specific a decision. Why should the solution need to pick and choose between these channels? Why should the solution care?
I’d thought of the term “Solution First” a few times prior to penning this post but again, a Google search will show you I’m not alone and I am certainly no pioneer. Many other posts and articles follow a similar train of thought to me, suggesting that all that matters is the focus on the solution. If that solution has mobile elements and desktop elements then so be it. If the development effort is streamlined and/or the UX improved by using a responsive approach, even better.
I would argue the only thing that matters is how your average user interacts with the solution – the user experience. Let’s take Facebook as an example – do we really think the average Facebook user is sat using their iFondleSlab commenting on the wonderful, responsive design? How easy it is for them to see the same content on their company desktop machine when their boss isn’t looking? Are they even aware that a bunch of hipster- developers somewhere are getting all hot and bothered over their cool new responsive build that seamlessly flows whether on a 7” tablet or a 60” plasma? In short, the answer is mostly a resounding “no!”
A Rudimentary Mobile Solution
Let me give you an example of my earliest experience with a “mobile solution”… After I finished education one of my first jobs was working for The Benefits Agency as an Admin Assistant, supporting the Adjudication Officers (AO’s) in their reviews, meetings and decisions with customers. In reality, this was even less glamorous and interesting than it probably sounds – it was 18months of mind-numbing boredom and saw me running around like the proverbial. Anyway…
For a while, one of my key tasks each day was to handle file retrieval and storage. Now when I say file, I mean a proper card file full of bits of paper and documentation for each customer – these were all stored in a massive floor to ceiling filing system that ran the entire length of the office I was based in. There were lots of files. Even though much of the data was stored on a central computer system, back then there was still a massive dependency upon manually completed paper based forms and very few, if any, were transposed into digital format in any manner (I wonder if that situation has changed over the years much?) The AO’s needed the customer files so they could review the content before, during and after meetings and review decisions.
So, each day the AO’s would have a diary full of appointments, a requisition list for transferring customers to offices in other areas (typically in the case of house moves) and a slow stream of incoming files that we had requested from elsewhere. In short, there was a constant flow of files moving all over the place. I’d manually move files from desk to shelf, shelf to desk, desk to mailbox, over and over and over again. Did I mention it was mind-numbing and I was like a blue-arsed fly?
Let’s fast forward to a typical modern day salesman type role, using a Sybase/SAP mobile solution and see how it roughly compares to my old role in the BA:
Activity/Object |
BA Paper Pushing |
Sybase/SAP Sync’ing |
Daily appointment list |
Review paper diary |
View Calendar software |
Customer data |
Physical files on shelves |
Customer master in ERP database |
Handle new customer file(s) |
Manual lift & shift and import to shelves |
Create customer master manually/via automatic interface |
Before appointment review |
Browse historic decisions & reports |
Browse historic orders/reports/dashboard |
During appointment |
Complete forms, notes, etc. |
Update forms, notes, orders, etc. |
After appointment |
Complete close out documents and send back for filing |
Commit new data updates back to system |
Ok, I realise this is a somewhat contrived (and very boring) example but I’m hoping it is becoming a bit clearer where I’m going with this. You could argue (maybe not very convincingly) that I was the mobile solution. I was the one taking data from a source and presenting it to a user. Technology in both hardware and software senses has enabled much more complex and advanced versions of this solution but the underlying requirements haven’t really changed that much.
Another, more modern, example of what I consider to be a truly mobile solution is how Google Chrome sync’s my bookmarks, user data, history, etc. across all devices I use. I don’t know how I used to work without this feature on my laptops, desktops and mobile devices. You will note I class this as a mobile solution, even if I only use it on my desktop or laptop devices.
It’s been a slightly meandering journey to this point. Hopefully you are still awake, interested and reading. After everything I’ve said above, just what do I define as mobile? Well, for me the key isn’t the device, it isn’t the app, it isn’t the fact that you are doing something on the 07:05 out of London Euston. It is all about delivering data and/or functions to a target, whether that is a human or system, irrespective of where the source is and where the target is. Whilst doing my best impression of a bluebottle at The Benefits Agency, I was enabling a mobile solution for the AO’s and their customers; the early Sybase CRM Sales solution was enabling mobile working for sales forces and their customers in a similar manner. The aims of mobilising were the same but the method of delivery had evolved.
We’ve probably all seen the articles and posts flying around places like LinkedIn of late, stating B2B and B2C are being replaced by H2H (Human to Human.) Well, I think what we are moving towards is of a higher level of abstraction. I think P2C (Provider to Consumer) is the true aim of any solution. It doesn’t matter what, where or how but we live in an age where all manner of devices, systems and people are accessing data and functions. Mobility is still defined as a special situation, over and above the de facto features of any solution. I don’t think it will be long before mobile, responsive, H2H, etc. are terms confined to history as we simplify our approach to building solutions back down to a P2C approach and these specialist features are just accepted as the standard.
And for those who are getting twitches and cold sweats, I’m not talking about SOA 2.0 – nothing that heavyweight or complex. A P2C, solution first approach should probably be based on lightweight, flexible protocols and development methodologies. I’m sure we can all think of some current, appropriate SAP technologies that logically fit into this camp, nevermind candidates in the wider IT industry. I don’t believe we need to search for any new technology to deliver this, we typically have almost all of what we need at our disposal right now. I do think we need a bit of a mindset change, some refining rather than rebuilding though. I already see this happening in the SAP world and assume it is on-going in the wider industry.
What is mobile? It is the deployment of solution first, P2C enabled technology that goes where it is needed most.
Very well done and a great blog. It is food for thought for sure.
Technology should be about solving business problems; yes I forget that from time to time too but blogs like this bring me back to reality.
Hopefully others will read it end to end.
Thanks Tammy - yeah, I think it got a little too long!
Intelligent people find these types of labels odd because they are marketing rubbish for the masses. You see, there are people who make a living selling these ideas and "new groundbreaking concepts" to companies, and they do need to make a living.
I was attending a conference where someone said that mobile commerce was going to overtake e-commerce. I asked too questions:
- By e-commerce you mean pages directed at laptops right? These laptops have more battery life then a tablet nowadays;
- By mobile commerce you mean tablets AND smartphones? It's strange to divide e-commerce from mobile commerce, and then put tablets and smartphones in the same basket (ask anyone who has developed UI for tablets and smartphones if they are similar). And I believe many people use tablets at home, so the whole mobile thing is subjective, but that's my personal belief.
Companies must have a multi-channel approach which means they have to make the applications consumable in laptops, tablets and phones. Neither is first, the solution should be scalable, with a solid backend and UIs adapted to each platform.
When I design a new solution I make sure that the underlying data is accessible, in the same way, to multiple UI technologies. That's my main design criteria, a laptop app should access the data and business logic in the same way as a SAPUI5 app, or a ASP.Net MVC app. OData is a great protocol to achieve that goal.
Hi Joao,
Thanks for a brilliant reply and for echoing exactly my thoughts. You've summed up my opinion perfectly.
Cheers,
G.
Cool.
Nice blog Gareth,
I think the Mobile First strategy has its uses. I remember the first time we tried to port VA01 (Sales Order) to a mobile device, we obviously needed to reduce the number of fields available in the standard SAP GUI (Or the end user would have to scroll for ages for every single page). When we then ported the solution to a desktop environment (Portal or NWBC) the cool thing was that the application retained it's user friendliness. So a bit more effort with the design thinking part and a mobile first approach even makes old school developers like myself able to come up with user friendly and multi-device capable applications.
But your "ramblings" are important and it is great that people question the buzzwords in the industry π
In your VA01 scenario the "mobile first" approach retained the user friendliness because it streamlined VA01 to the way it is used in your company. And you had to streamline it, since VA01 would be unusable in mobile. As a corolary, that is why I believe mobile is intrinsically a custom development, there is no way to make a generic, fit all, mobile application (with exceptions of course, like the standard list/detail apps, like PO approval).
In the end It's a bit unfair comparison since VA01 needs to support the processes of all companies while our custom versions are hand made for specific companies. π
That is why I used VA01 as an example. We have loads of customers using the solution, but since we do not believe in Vanilla solutions in the SAP space all customers add their specific needs on top of a template.
My point was not that every customer should have the same solution but that a "mobile first" approach really challenges you to think about the fields and information an end user truly needs as the screen of a phone is really small.
So blowing it up to desktop without adding loads of fields (and turn it back to the static generic VA01 in the SAPGUI) has some advantages when you try to achieve user friendliness. And I know that using a desktop with a keyboard and mouse is different than a tablet or a smart phone.
Lots of valid points, however I tend to agree with Njål, from a design perspective starting with smaller screen does help to focus the mind on the important elements of a process.
This doesn't mean the mobile and desktops UI's have to be exactly the same, or that the desktop top is a second class citizen, just that if you can come up with a simple design that works well on a small screen, it should be easier to enhance/add features, than starting from a big canvas and trying to squeeze onto a mobile device
I don' think this limits you from having a more feature rich version for desktop, on the SAPUI5 Mentor Monday call yesterday Andreas also mentioned that they are looking to make some the the sap.m controls behave differently on a desktop, rather than just stretching.
Many thanks,
Jason
On the other hand an application is much more then the UI, and the backend/business logic has the opposite logic. With limited functionality you may be tempted to make a less scalable/modular backend, which then fails to scale when you add more functionality. What I am saying is that there is little reason to limit the design of the entire application (which includes the backend services/business logic) based on the UI, in the end you are eventually going to build a UI for desktop/tablet.
While Mobile first may have the benefit on the UI side of forcing you to streamline, you may end up limiting the experience you want to provide your end users.
Hi Joao,
Agree, I'm not suggesting that you don't consider aspects of the overall application as part of the design, just that I believe starting the UI design from a simplistic starting point has it merits, as it makes you challenge the core functionality a lot more.
As with most things there is always hype, but if you can get past the buzzwords, pick out what works for you, I think it adds value to your overall design approach.
Many thanks,
Jason