Unit4 is at the forefront of the next major technology shift. AI, Bots and self-driving systems will revolutionize the enterprise technology market thanks to an entirely new way of communicating with computers. For the first time in history, we can communicate in natural ways, and be guided to complete tasks in quicker, better ways. This new user experience is an attractive thing for companies that need to attract young talent.
Legacy software vendors that traditionally provide on-premise solutions still face a couple of architectural challenges. Those allow them to provide cloud-native applications as well as a solid foundation for offering a natural bedrock on which to construct bots, ultimately allowing them to offer a conversational user experience.
Many vendors of legacy software struggle to accomplish a smooth transition from a monolithic architecture to a cloud-enabled service oriented architecture, as such a transition involves rewriting, which comes at a significant price. However, the previous economic benefit of re-architecting to ensure a more efficient use of compute and storage resources is gone due to increasingly cheaper IaaS and PaaS services.
HTML5 and JavaScript seems to be getting a lot of attention and being pushed as the next great set of technologies for write-once-deploy-many for mobile devices. If that crystallizes it would be great – wouldn’t it – like a nirvana for software developers. Imagine only have to develop once, and by sheer miracle you support n number of platforms. Brings back memories from similar pitches and discussions when Java was invented.
I’m not concerned with HTML5/JS as technologies, but more the perception that those specific technologies (could be any technology) are THE silver bullet that’ll allow you build build once-and-deploy-many without additional work. Similar pitch and hype that surrounded Java initially – and that didn’t really crystalize. Even if HTML5 becomes the predomination approach for rendering UI on a variety of devices, none of the devices will share equal characteristics, literally meaning that there’ll still be work – and sometimes significant work – to do for each specific device you want to render against, e.g. there’s a huge difference between the UX/UI on an iPad and an iPhone, that won’t be automatically resolved by using HTML5 – nor will it be automatically resolved using native tooling. A very good example of this, was that initially everybody believed that users would accept viewing web pages designed for desktop browsers on their mobile devices. It quickly turned out, that companies not offering a special tailored mobile version of their web lost viewers, and HTML got extended with features to determine whether or not you were on a mobile browser, and would then redirect you to a special mobile web page.
Take the above into consideration when vendors argues that you can support a number of different devices with same code base. It’s partly a true statement, as long as the screen doesn’t change too much. As soon as you change the screen you’re HTML based application will either sit nailed in the top-left corner or scale all elements to fit the new physical screen dimensions. Either way, there’s a huge risk that your app ends up looking skewed. To avoid that you’ll have to implement logic to accommodate that. In the event that you aren’t too concerned with the look, then this is a non-issue. But you may lose users or people will rate your app as unattractive.
There’s also the challenge of using the native capabilities of the devices. Vendors of platforms offers different levels of API that maps to the underlying OS, and recently they’re starting to push the notion of plugins – like PhoneGap. These plugins allow you to develop native code that you can call from JavaScript, which is nice, but it does raise the question why this is needed. My take is that it’s needed simply because the API offered aren’t always extensive enough to support all possible permutations of usage of the underlying OS. But seriously, if you have to do that – what’s the whole point using HTML5/JS then, as you end up having plugin code for each device that you need to maintain.
Almost every vendor of cross-platform tooling based on HTML5/JS web pages states that the key driver for using these tools are the ability to repurpose skill sets that your web developers already got – HTML and JS. Instead of having to learn new technologies. Simply because that’s cheaper than having to hire iOS developers, which are hard to get by and notoriously expensive. The funny thing is that on Android and RIM the language is Java, something that most HTML/JS developers knows as well – or C# for WP7, which all .NET developers knows (Visual Basic will be added).
On the native side, an idea could be to encapsulate anything that concerns business logic in a device agnostic language like JavaScript or Lua scripting, embed that in the native application and only focus on UI/UX when writing native code. It’ll give you total access to the underlying OS, all it’s capabilities and ability to build whatever you want without the additional abstraction of HTML5/JS and wrappers. The abstracted code can be maintained centrally and extended without impacting the native code, e.g. if there’s changes to validation rules you can update the library without having to change one single line of code in the native applications.
Long story short, my reluctance isn’t about the technologies, but about the perception that we all of a sudden can support all possible permutation of devices and OSes just by using HTML5/JS. Which won’t be the case.
Here’s a thought maybe even a provoking one, as everyone seems to have reached at the conclusion that wizards in software are good. The general and agreed upon argument goes; that a wizard shields the underlying complexity of the software. That’s fine. However, the question quickly becomes for whom or why do you need to shield this complexity. For the user, mostly the casual user, as the assumption in software design for business applications seems to be that the non-casual user knows how to operate complex screens or at least have read the manual.
But why would a casual user need to use the same software as a power user? Or at least why and where do a power and casual user share the same area and functionality of a certain application? Wouldn’t it make more sense to build different screens targeting the primary user – being either casual or power user? Rather than trying to cram everything into one screen? And then after cramming everything into one screen for the power user, develop wizards to help the casual user?
I can think of one specific area where wizards do make sense mostly concerning installation, configuration and setup of applications. But that’s not really shielding functionality, that’s more semi-intelligent template generation.
It should trigger a warning if you’ve either designing an application and you’re thinking: “maybe we should implement a wizard to make it easier”. Warning, you’re heading down the path of providing an uninspiring solution to a bad design. Don’t go there. Stop and rethink your design and redesign so the application targets the primary audience and provide the level of functionality needed for that audience. Strip away unnecessary functionality, and stuff it somewhere else, and let the power user go seek it out if needed.
#programming #wizards
Claus Jepsen 