Hybrid Web Container (HWC) is Not the Answer
The Problem
I have a problem with the Sybase Unwired Platform (SUP) Hybrid Web Container (HWC). When I first saw the functionality, I couldn’t quite get my head around why it felt like such a “cheap” solution for a clearly globally fundamental problem. Before I dig into my analysis, let’s talk about the reason this functionality exists in SUP. SUP, as it’s positioned, is supposed to alleviate a lot of the pain that mobile development groups go through when trying to deliver mobile applications to their clients (the business, normally). The major pain points:
- Developing for multiple back-ends
- Developing for multiple devices
- Developing for multiple front-end/GUIs
These are all large problems to do with one thing; accessibility. As Steve Yegge has rightfully pointed out “…Accessibility, and it’s the most important thing in the computing world.” So how does the HWC solve these problems:
- You create Mobile Business Objects (MBO) so that the ‘model’ part of the mobile design is only design once and can be reused. In the case of HWC, the only real advantage here is that you can easily maintain and connect to popular back-ends (such as SAP, REST, JSON, etc)
- It utilizes jQuery Mobile which fully supports a plethora of devices and platforms.
- By utilizing jQuery Mobile it means that you can highly customize the design and UI. Also the HWC functionality allows you to easily add your own custom HTML/JS.
The HWC Solution
What does this mean for the end-user? They get a native app (iOS, Android, Blackberry, Win, etc) called “Workflow” which then lists the set of HWC apps that have been deployed to them. The developer then has the ability through the SUP environment to deploy these HWC workflow apps to specific devices. Effectively all the native app is doing is acting as a holder for a webview class. For example, in iOS development there is a class called UIWebView that does this. Which means there is very little native code in the app, other than really just calling this webview class. So what does this mean?
- It relies heavily on HTML5/JS
- It relies heavily on being connected to the server. Meaning, pretty much any navigation on the app must make a call to the web server (SUP Runtime) and wait for a response. (note – in some cases asynchronous AJAX calls are possible)
- Offline storing is extremely limited.
The HWC Solution Problem
So this sounds great right? I have a couple of issues with this setup:
Accessibility
Accessibility is absent when the end user has no connection. No connection == no accessibility. So the accessibility argument effectively gets thrown out the window even before starting. There are some ways around this using the HTML5 spec localStorage, but I have yet to see this functionality work properly and in the way that a native app works. In other words, I have to see an offline HTML5 spec that can compete with the functionalities of something like Core Data.
User Experience
While jQuery (and other platforms such as Sencha, PhoneGap, etc) has solved many of the issues around the UI being presented, it still doesn’t represent the native app experience. People do not adopt smartphones for the smartphone itself, but rather for the apps that exist on them. Mark Zuckerberg recently came out and explained “the biggest strategic mistake we’ve ever made” was using HTML5 for their app. Facebook’s app was slow, chunky, and for the most downloaded app in the world, had a measly 2-3 star rating in the iTunes Store.
The Real Solution
So what’s the solution? I believe in the 80/20 Native/Hybrid approach. It’s what Facebook, LinkedIn, and a plethora of other leading mobile companies are using to create their apps. Unfortunately what this requires is a lot of up front work in understanding how the mobile app is used. To be very clear; this is how the mobile app is being used, which is slightly different than the back-end app that is used on a PC. This is extremely important and many companies choosing to develop mobile apps will often underestimate this. The reason this is so hard is because it requires many iterations of usability testing (something that pretty much never happens in EnSW), specifically around how the app is used in low latency and offline situations.
The focus of the SUP platform for developers should really be on creating MBOs that allow the developer to provide an infrastructure for managing all the changes to model objects. Which would give automatic support for undo and redo, and for maintaining reciprocal relationships between objects, across all platforms, while balancing the model layer between HTML5 and native interfaces. As I dive deeper into the platform, I’ll be finding more and more if that support is true.
Before you say: HWC is not the answer, you have to first ask the right question. Saying: do not fly, take a train is the wrong answer to the question: how do I get from LA to Tokyo.
SUP is serving a different user base than the native apps you find in an app store. For a company the need to develop a native app is close to non-existent; and if they have to, the UX is not one of the top priorities.
Stating that HWC offers a bad UX because Facebook is incapable of contracting good developers, well, that's actually Facebook's problem and not related to HWC.
The real problem with HWC is that SAP decided to artificially limit the container to online apps. That a HWC app cannot work on a preloaded data set is strange, but it looks like SAP will change this and make HWC offline capable.
I was slightly confused by your comment at first as your analogy doesn't really fit, but I think I know what you're trying to say...
First, technically SUP is serving a developer user base. So, I think what you're saying is that enterprise mobile applications don't serve the consumer mobile web. Fair enough, but what about the consumerization of IT? Are LOB and business users not signing up for services like Dropbox or Basecamp to alleviate their usability concerns with Sharepoint and MS Project? Or why are organizations implementing BYOD policies?
It also sounds like what you're saying is that SUP makes is easy to expose existing enterprise back-end (i.e. SAP) systems to mobile devices, with little or no need to analyze how the mobile app is being used by the end-user. If this is case, then why doesn't SAP just make apps very every single back-end application they have in their catalog? Today they already do, and customers aren't adopting them. SAP themselves have said the apps are more to display "the art of possible" and get partners to deliver "80%" of the mobile solutions.
The user experience of HWC is bad because it is extremely limiting. The reason I brought up FB was because it once was fighting against accessibility issues and used a HTML5/JS strategy that simply didn't work. Technically speaking what Facebook did was to try to access multiple UIWebViews in parallel which in turn crushed the CPU and lead to a clunky terrible user experience. The HWC is literally one large web browser UI container powered by a SUP web application back-end. From what I've seen there is literally no reason to use the workflow app, other than for ease of deployment use to end-users. Why not simply provide every back-end system with responsive web design views and have the user use Safari, Chrome (Android), etc?
That's not a limitation with HWC, that's a HTML5 localStorage limitation. How are you supposed to persist data effectively in a web container? The only thing I can think of is if they somehow build in database libraries in the workflow app that would persist data in the native device. (possibly via SQLite?)
I believe the overall problem for mobility solutions was brought up in a discussion I had recently with Jarret Pazahanick about how many customers (HR in his case) are looking at cloud solutions partly because the mobile apps are integrated and embedded in the technology at point of sale. It's a feature of the overall product, not an add-on. Interestingly, these same cloud companies that are starting to become a threat to SAP solutions, like Workday and SalesForce, are focusing on user experience and mimicking the Facebooks, Googles and Amazons of the world. Don't believe me? Watch this:
http://www.youtube.com/watch?v=dWawiKa50Xo#t=29m48s
Hi Michael
I wont lie much of the article is over my head from a technical standpoint but I will chime in since you mentioned our discussion on Twitter. I do not see adoption from SAP HR customers with the current model and it is not because they dont want it but yet it is to expensive. Every "delivered" SAP HCM mobile (wrote about here SAP HCM Mobility and Roadmap) requires Sybase/Gateway and several of the 3rd Party apps have even an extra cost and my views havent changed much from here Is SAP Using the Right Mobility Strategy
On a side as you mentioned all the SaaS HCM vendors including SuccessFactors are including mobile as part of their subscription for no additional cost and thinking with a mobile first approach on all their design. Why should a SAP HCM customer pay EXTRA for the same functionality that their SAP owned SuccessFactors customers do not.
On a side if I am using the SAP Mobile Store correctly there are still not even 100 apps available and the uptake on partners developing 80% of the apps seems a long ways off.
Jarret,
last time I checked there were 88 offerings available in the SAP App Store. That's close to nothing. Worse: not all apps are available globally, depending on your location the total number of available apps is < 20. Giving you not much choice.
I have my doubts that the number will go up in a reasonable way, as for sure many partners will focus on the typical SAP mobile problems (workflow, travel, HR), and having 15 apps for the same tasks gives you effectively ... 1 app.
Curious, how many apps would you expect?
FYI - There's currently 184 in the SAP Mobile App Store in EMEA:
https://www.sappartnermobileapps.com/showcase.php
I can't even get on the official SAP Store because it was built in SILVERLIGHT and don't have it installed. Who on earth made that decision?! Does any mobile device support silverlight?
Take a closer look at HWC: HWC is responsible for storing and sending the data, not the web page. When you run a HWC app in your browser you'll see that the "save" is sending the data to HWC (POST to sup.amp), and HWC is than sending the data to SUP.
You are blaming HWC while using it in the wrong context / use case. SUP app in general are not intended for non-corporate users, even when they bring their own device. It's not a simple: download the HWC app and start accessing your corporate systems. Just because employees are bringing their own device does not mean that they won't need to adjust their expectations when using a corporate app: user registration, app registration, user assignment, app distribution, etc.
Good point Michael !
I like to say "use what they use" meaning that first of all it's important to map and study what SAP itself is using for the packaged solutions.
About the Mobile Apps, some months ago John Moy posted the beautiful blog Charting SAP's mobile apps that then kindly copied in the wiki page at http://wiki.sdn.sap.com/wiki/display/mobile/SAP+Mobile+Store+Apps that I'm helping to maintain updated.
Guess, no SAP standard App is HWC based.
For this year, have fun developing MBO native Apps 😉
How should they? Most SAP apps use Gateway and/or DOE. Using mobile apps to get Gateway out to clients was SAP's decision. As you cannot use Gateway with HWC, you have to make it a native app. When offline capability is included, HWC automatically is ruled out.
Hi All,
From the moment Gateway was announced and SAP decided that it would be a pre-requisite for some (all?) of their mobile applications; I wondered what their strategy actually was. So many times I've picked up or had demonstrated to me new SAP technology or solutions in an existing technology, been blown away at what they offer or the problems they solve. Then the conversation/demonstration progresses to discussions about licencing and costs and you quickly realise the product is potentially dead in the water.
If you hold the purse-strings for an organisation's IS spending and you are requested to sign off on a smallish rollout of ESS/MSS timesheet approvals for instance, how are you expected to reconcile investing in Gateway and SUP on top of your existing landscape? Factor in any required backend config/customisation if it’s not already in place, then the almost guaranteed need to customise the mobile app itself and you suddenly have a big project for what appears to be a smallish return in terms of functionality. If you have a large mobile user base or are considering multiple applications and therefore probably should go for a MEAP too, you then have to add in Afaria (or similar.)
Cost vs. benefit - does not compute. (Or does it?)
For me, this challenge highlights what is most difficult to grasp in terms of a mobility strategy for any organisation... The organisation is typically going to have to put in quite a significant initial expenditure and effort for what may potentially only be a single app deployed to a small percentage of its workforce in the first instance. Mobile app's, by their nature, are typically small in scope and focus, and seem to align with the modern world's desire for everything in small, short bursts with little overhead. That just doesn't stack up against the initial outlay to roll them out. For me, there is almost a fundamental conflict between how most people perceive mobile applications and their use, versus the efforts, resource and ultimately cost, required to deliver them. I think this picks up on Tobias’ point about the difference between consumer applications and those designed with more of a corporate target user base.
What I believe is needed is an acceptance that the initial setup costs and effort for mobile solutions don't necessarily stack up against one individual app. Similar to the Netweaver Process Orchestration platform for instance, or HANA maybe, you are investing in a platform that is the foundation for your organisation's entire mobile strategy over a longer period of time. It doesn't have an overnight payoff, it doesn't solve all problems and it probably isn't the magic bullet to mobilise everything for everyone, however it starts you down that road and will support those aims in the longer term. In short, should it become an OpEx instead of a CapEx? (I don't know - I'm just a developer!)
From a purely developer's perspective, I know from personal experience working with one of my colleagues Martin Shinks, you can very quickly and easily create a mobile app on the Android platform that interacts with an SAP backend, using just industry tools such as PhoneGap and knowledge of RFC's and related technology. The effort to re-produce that app with Sybase involved goes up quite a lot. What do you gain? Data synchronisation, MBO design once deploy multiple times, easy integration with many back ends via industry standard protocols, etc. These are all very much technically driven benefits though. I can't see many CFO's getting too excited about them. But just you go and try to build this sort of functionality by hand, without something like SUP in the way - good luck I think. Never mind the inevitable disaster months/years down the line when you realise everyone in your organisation has different versions of your applications, people who have left still have access via their own devices, and you’ve created a massive spider-web development platform using all different technologies that requires large resource and time to maintain and support.
Martin's app is great (it's a proof of concept to reprocess IDOC's from your mobile) as long as you have a data connection and a backend system that is up. HWC applications although relatively simple, don't necessarily need to have a permanent data connection. You can sync your approval requests in a departure lounge or as you leave the office, then work through them on your plane/train/automobile (please don't SUP & drive!) and they will be sent, via SUP, into your backend system when you next get a data connection. Likewise, if you arne't connected when an approval is sent to you, it will be picked up next time you are.
This leads me on to a further point - HWC used to be called Sybase Workflow. Whilst that was misleading (more accurately they should have been called Workflow Tasks I think) it is an important point - the features available just aren't designed to be an alternative to a proper native app. HWC is all about simple, lightweight approval type apps (hence the old Workflow moniker) not all singing, all dancing multi-function apps. But the fact you can re-use MBO’s across both your HWC and native app’s is an instant bonus, at least for developers. Whilst SaaS vendors may be able to deploy applications for free as part of their core licencing model, how many of them support the kind of off-line synchronisation and device management you can get with SUP & Afaria? I guess the other side of that coin is how many organisations believe they need that level of functionality? I'm not close enough to the SaaS solutions to answer those questions unfortunately.
I think I’ve probably rambled on enough now. I’ve got carried away with a bit of a brain dump (coincidentally because I have time whilst I wait for my Sybase SUP installation files to download to re-install my local dev system, after I accidentally wiped all of my installation media yesterday!) I’m not 100% sure all of the above is accurate but it’s where my head is at the moment in terms of SUP.
Gareth.
Great reply. A couple of comments:
Correct me if I'm wrong, but basically any pages generated in the HWC are generated by the back-end server (and not the app). In other words, the HTML generated in the HWC is generated by the web application server on SUP. Which means even if I navigate to a page (let's say you are on a dashboard page for an approvals app and then click one of the approvals you already made) it means nothing will be generated and as you point out you can't do any server interactions (like update, delete, etc).
I would assume off-line synchronisation is simply engrained in the technology. It's a lot less of a challenge when you create the underlying technology yourself. The value of SUP is that it's agnostic to what the back-end is doing. MDM on the other hand, no problem, just use Afaria (or Good/AirWatch/etc).
Correcting: the pages are HTML + CSS + JS and saved on the device and accessed locally. The data that fills the page with usable content comes from the MBO, and that data comes from the backend, like: sales order, user data.
You can have several pages in HWC that will work in offline mode, as long as they do not need data from a MBO. If you like, you can create a HWC app for offline documentation when the docs are stored on the device.
You can also have a HWC app that does not load data from the backend, as you only enter new data. This app will work in offline mode. As soon as your device is back online, this data will be sent to the backend.
Sounds good... but not that much. An average Workflow Package (HTML's, Js, Css and Images), with little customization, implies in a 500k download on the device (we have measure it here).
Now took an average manager, with 4 Workflow associated. For the first time he/she access the HWC, it has to download 2Mb in files. Believe me: in a poor 3G network (like the one we have in Brazil), it took a while...
Notice that the HWC does not show any progress or user feedback, other than the topbar Activity Indicator.
What's worst: I can't easily customise the HTML to make it light. It is all automatically generated by the bogus Eclipse Workspace 🙁
The initial workflow package download is not optimized by SAP, but nothing stops you from doing the work SAP should have done. The problem is that obviously using minimized Javascript was not on the to-do list for HWC. The jQuery (mobile) library is the non-minimized version, and in 2.1.3. you also get Phonegap, if you use it or not. The Javascript from HWC is also not minimized.
The file that is generated is a ZIP file, feel free to minimize the included Javascript with a tool you trust.
Next problem is that it looks like the file is a generic one. SUP makes no difference if you are using Android or iOS, you get the generic code, including checks like "if this is Android, then do xyz".
Of course this increases the size of the transmitted file. About the data connection ... well, talk with your provider or make sure the user connects from time to time to wifi. Would be nice to have a HWC feature that states: only download packages when connected to wifi.
One area I would definitely agree needs improving is the actual Workflow application on the mobile devices. On iOS, other than setting up your relayserver/SUP server details there is little a user can do - this is probably a good thing for end users but is a complete pain for developers. At least with Android you can view logs on the client device which is something but not much.
In terms of the size, this is ultimately the price you pay for deploying build once deploy multiple times applications. I'm not sure if Afaria has some control over only pushing updates and/or new app's to devices when on wifi or not? Of course if you haven't got Afaria it doesn't matter!
Gareth.
Last year I did 3 offline apps with SUP HWC. It's not true that you need to be online to use it.
It's true that the functionality is limited, you can't do apps that manage big amounts of data but it can be a good solution for this approval apps.
PS: I did 2 offline approval apps "initiated by server". The applications consist in sending the notification from SAP of a pending approval to the device. When the device is online (withou user interaction) it receives the notification AND gets the data from SAP.
Then when the user opens the HWC app, has the document data, and can navigate and approve it without any connection. When the device is online again, the approval/rejection operation is sent to SAP through SUP.
I know the apps are very simple, just receive the notification, check the document data and approve/reject. But it works offline
"I know the apps are very simple, just receive the notification, check the document data and approve/reject."
Sometimes that's exactly what you want though - and I believe exaclty what HWC is meant for.
Gareth.
I'm not quite sure where this discussion is supposed - there's much more in SUP than just HWC, right...?
Frank, absolutely. I'm just talking about one of the key problematic areas of mobility development - device fragmentation (and subsequently accessibility) - and SAP's technical solution to fix it.
Note - The recent partnership announcement with AppAccelerator is a big step forward in solving this.
Of course - you have the option of three "levels" of app essentially:-
This is an important point and I think goes back to Tobias' initial response - you need to use the correct solution, or "ask the right question" to ensure you get the right answer.
For me, HWC is perfect for simple approval type solutions, or one shot functionality. We are currently building some proof of concepts to use simple SUP HWC app's to wrap BPM processes, so we can mobilise the approval steps. If we wanted to mobilise the more complex steps, or full on applications, we'd no doubt go for a native app implementation (its next on the list.) And if we decided we wanted to offer some simple reporting from BPM datasources we could probably use the OData SDK and Gateway.
As the old saying goes, it's horses for course. 🙂
Gareth.
Michael - I can't agree with you here. A better metaphor might be: the camel is a stupid animal and therefore the car is a better mode of transport.
Take my customer as an example: they needed to get 4 simple apps - approvals and the like - out to their BYOD heterogeneous collection of Blackberry, iPad, iPhone and Android devices. We did this in 12 weeks with a small team including infrastructure procurement and build, installation, back-end configuration, device management with Afaria, security and firewall configuration, app build, testing and deployment.
Everything you say from a technology perspective is fair: they sacrificed some usability, functionality, online/offline functionality and flexibility as compares to a native build. In addition, SAP need to put some work into optimising HWC some more, as others point out. And that makes HWC a bit of a camel.
But, in return they got 16 apps in 12 weeks, very fit for purpose, including the security and deployment model that works for public sector. Here is the YouTube video where I interviewed the customer.
http://www.youtube.com/watch?v=NYaXT-tKs54
In the spirit of weird metaphors in this thread: it's camels for courses.
Regards,
John