Posts Tagged ‘Programmers’

Vertical User Experience Platform

July 5, 2012

Whilst discussing what a UXP is and who the key players are with a customer I was asked an interesting question, “is there a need for industry (banking, retail, government …) specific UXP ?”.

My immediate reaction was that the technologies in a UXP were generic horizontal solutions that should be agnostic to the industry they were implemented in. The fact that they were specialised solutions and are not industry specific to me was a key advantage. So why would you want a content management solution or collaboration tool that was specific to banking or retail?

The response was interesting: For many smaller companies the complexity of managing their web presence is huge, even if they buy into a single vendor approach for example using Microsoft Sharepoint they still have a huge task to set up the individual components (content management, collaboration, social tools and apps) and this is only made harder with the need to support an increasing array of devices (phone, tablet, TV etc…).

It seems there is a need for an offering that provides an integrated full UXP that can be set-up easily and quickly without the need for an army of developers. Compromises on absolute flexibility are acceptable provided a rich set of templates (or the ability to create custom templates) were provided, such that the templates handled device support automatically. Further the UXP might offer vertical specific content feeds out of the box.

As in my previous blog “The End of Silo Architectures” using a UXP front end technology to create industry specific apps is a great idea. Such a solution could not only provide the business functionality (e.g. Internet banking, insurance quotes/claims, stock trading) but the technical issues of cross device and browser support, security and performance.

So whilst I can understand the requirement and the obvious benefit, the idea of a vertical UXP to me seems like providing a vertical specific CRM or Accounting package. The real answer is that it makes sense to provide vertical apps and use generic Content, Collaboration and social tools from a UXP. Ideally the generic components are integrated and have easy to configure templates.

As I have highlighted before though the UXP is complex not just from a technology perspective but also from the perspective of skills, processes and standards. The first step for any organisation must be to create a strategy for UXP: audit what you currently have, document what you need (take into consideration current trends like social, gamification and mobile) and then decide how you move forward.

Unfortunately this area currently seems ill serviced by the consultancy companies so it may just be up to you to roll your own strategy.

The end of silo architectures

June 28, 2012

From my discussions with customers and prospects it is clear that the final layer in their architectures is being defined by UXP (see my previous posts). So whether you have a Service or Web Oriented architecture most organisations have already moved or are in the middle of moving towards a new flexible layered architecture that will provide more agility and breaks down the closed silo architectures they previously owned.

However solution vendors that provide “out the box” business solutions whether they be vertical (banking, insurance, pharmaceutical, retail or other) or horizontal (CRM, ERP, supply chain management) have not necessarily been as quick to open up their solutions. Whilst many will claim that they have broken out of the silo’s by “service enabling” their solution, many still have proprietary requirements to specific application servers, databases, middleware or orchestration solutions.

However recently I have come across two vendors, Temenos (global core banking) and CCS (leading insurance platform) who are breaking the mould.

CCS have developed Roundcube to be a flexible componentised solution to address the full lifecycle of insurance from product definition, policy administration to claims. Their solution is clearly layered, service enabled and uses leading 3rd party solutions to manage orchestration, integration and presentation whilst they focus on their data model and services. Their approach allows an organisation to buy into the whole integrated suite or just blend specific components into existing solutions they may have. By using leading 3rd party solutions, their architecture is open for integration into other solutions like CRM or financial ledgers.

Temenos too has an open architecture (Temenos Enterprise Framework Architecture) which allows you to use any database, application server, or integration solution. Their oData enabled interaction framework allows flexibility at the front end too.

Whilst these are both evolving solutions, they have a clear strategy and path to being more open and therefore more flexible. Both are also are providing a solution that can be scaled from the smallest business to the largest enterprises. Their solutions will therefore more naturally blend into organisations rather than dictate requirements.

Whilst packaged solutions are often enforced by business sponsors this new breed of vendor provides the flexibility that will ensure the agility of changes the business requires going forward. It’s starting to feel like organisations can “have their cake and eat it” if they make the right choices when selecting business solutions.

If you’ve seen other solutions in different verticals providing similar open architectures I would be very happy to hear about them at dharmesh@edgeipk.com.

Is the dream of re-use outdated?

April 12, 2012

Since the early days of programming developers have chased the dream of creating code that can be used by other developers so that valuable time can be saved by not re-inventing the wheel. Over time, there have been many methods of re-use devised, and design patterns to drive re-use.

Meanwhile the business users are demanding more applications and are expecting them delivered faster, creating pressure for IT departments. Sometimes this pressure is counter-productive, because it means that there is no time to build re-usability into applications, and the time saved is just added on to future projects.

Could we use the pressure to take a different approach? One that focuses on productivity and time to market, rather than design and flexibility as typically sought by IT?

I’m going to draw an analogy with a conversation I had with an old relative that had a paraffin heater. This relative had the heater for many years, and is still using it today because it works. When I questioned the cost of paraffin over the buying an energy efficient electric heater which was cheaper to run, the response was this one works and it’s not broken yet, why replace it? Now for most appliances we are in a world that means we don’t fix things, we replace them.

This gave me the idea, which I’m sure is not new, of disposable applications. Shouldn’t some applications just be developed quickly without designing for re-use, flexibility and maintainability? With this approach, the application would be developed with maximum speed to meet requirements rather than elegant design knowing that the application will be re-developed within a short time (2-3 years).

So can there be many applications that could be thrown away and re-developed from scratch? Well in today’s world of ‘layered’ applications it could be that only the front end screens need to be ‘disposable’, with business services and databases being designed for the long term, since after all there is less change in those areas generally.

Looking at many business to consumer sites certainly self-service applications and point of sales forms typically could be developed as disposable applications because generally the customer experience evolves and the business like to ‘refresh the shop front’ regularly.

My experience of the insurance world is that consumer applications typically get refreshed on average every 18-24 months, so if it takes you longer than 12 months to develop your solution it won’t be very long before you are re-building it.

When looking at the average lifetime of a mobile app, it is clear that end users see some software as disposable, using it a few times then either uninstalling or letting it gather dust in a dusty corner.

So there may be a place for disposable apps, and not everything has to be designed for re-use. This is more likely in the area of the user experience because they tend to evolve regularly. So is it time you revised your thinking on re-use?

HTML5 takes on the cloud.

April 28, 2011

Thanks to Microsoft not only do I have to fix my friends and family PC (well actually Windows) issues, but they now keep asking me about the cloud. So in retaliation I’m going to write about the total opposite: how you can get web applications to run offline using HTML5.

There have been a number of open and proprietary technologies that have allowed applications to be delivered and updated through the web but to operate locally. Some of these have been dependant on plug-ins e.g. flash, Silverlight or platform specific such as Microsoft HTA.

HTML5 now brings with it features that not only allow you to run applications offline but also to store data and content with it too. Of course you may be thinking with 3G, 4G and Wifi we have ubiquitous broadband anytime anywhere, but you only have to take a stroll out of the city to realise we are not quite there.  In fact the success of mobile apps has highlighted the need for local offline applications.

First an application can check whether it is online or offline by checking the navigator.online property (it is a simple Boolean). There are also events to notify an application of a change in status so an application can behave as desired in either it’s online or offline state.

HTML5 allows you to define a “Manifest” , essentially this simply lists the files (pages, images, scripts etc…) an application wants the browser to store (cache) locally so that they can be read when offline. There are also events and processing that can be programmed to control how and when the cached pages are refreshed, this includes the ability to show progress bars whilst a large application is being downloaded to the cache.

There aren’t many applications that don’t rely on stored data. HTML5 WebStorage specification provides new API’s for persisting data as simple key value pairs. There are two options here: sessionStorage or localStorage. The key difference between the two is how long the data is kept for. Simply, if your application just needs data whilst it is currently running (and not after the browser is closed) then use sessionStorage , otherwise if your application needs data that can be used after browser re-starts use localStorage. Although this sounds similar to cookies, these API’s are far more efficient and can store far more data than cookies. Both options provide getItem, setItem and removeItem methods for retrieving, storing and removing values. There are also events that can be trapped and processed by an application when data changes. For me the WebStorage specification is one of the most exciting as I have previously blogged the need for “client side session management” to improve performance and efficiency of web applications.

In many applications this simple storage of data will not be enough and users will want much more the capabilities of a database that can be queried and sorted. Here the IndexDB specification comes to the rescue. This specification deserves a blog post in it’s own right, so for now I’m going to leave it as HTML5’s answer to having a local database capability.

So HTML5 brings a host of features to make rich, dynamic applications with local storage work offline a reality. But we are still a way off from this being a ubiquitous solution as standards/specifications gets finalised and desktop browser’s play catchup with enabling these new features. However the time is right for your organisations to re-evaluate the technologies  used for offline applications as HTML5 is a serious contender for the future that is inevitably going to require a cross platform approach to both online and offline.

http://www.w3.org/TR/IndexedDB/

http://dev.w3.org/html5/webstorage/

http://www.w3.org/TR/2011/WD-html5-20110113/offline.html#offline

Does HTML5 mean the end of the road for Gears, HTA and Flash?

March 10, 2011

Web standard HTML5 contains loads of great features, from video playback to drag-and-drop. But the best bit, and currently one of the least talked about elements, might be the capability to run apps offline.

The normal web experience is hindered by connectivity. Users can typically access web apps while they have a connection to the internet. Once offline, individuals lose access to email, calendar or notes. There are, of course, workarounds. Google Gears, for example, allows users to navigate compatible sites offline and synchronise when back online.

Microsoft HTML Applications (HTA), meanwhile, is a Microsoft Windows formalisation that provides a web-like experience offline. And Adobe Flash can also be run offline, allowing users to run Flash-based content.

Such workarounds are OK but they are also a bit messy. People want the same experience online or offline; they want to get hold of – and manipulate content – regardless of location and they don’t want to be hindered by platform specific technologies or plug-ins.

HTML5 provides that standardisation. Its two–pronged approach re-connects the user through an SQL-based interface for storing data locally, and an offline cache that helps ensure apps are always available (see further reading, below).

With regards to availability, HTML5’s application cache mechanism provides the ability to have a fall back page for rendering pages when offline. It also provides a means to update cache dynamically. The key, here, is client-side management.

And without wanting to bang my own drum too loudly, it is a rhythm I have been hinting at for a long, long time. I blogged two years ago (see further reading) about client-side management as a method for keeping data in the browser, rather than the server, and as means to reducing memory and processing requirements.

“If only it was supported as standard by the browser rather than having to use hidden fields,” I concluded – and now that day is fast approaching. HTML5 creates a standards-based method for creating local apps that run offline.

As mentioned earlier, HTML5 also provides the ability to store data locally through a client-side SQL database. A series of apps could potentially work with this database, providing a new level of accessibility and integration.

The total approach represents a huge step forwards for web development. It also signals that the end is nigh for proprietary workarounds like Gears, HTA and Flash. HTML5 is the future and web developers simply must get with the program.

Further reading:

http://www.w3.org/TR/offline-webapps/

http://blogs.computerworlduk.com/facing-up-to-it/2008/07/client-side-session-management/index.htm

AppInventor to drop out of school

February 3, 2011

Something odd is happening. While children have never been more involved in computing, fewer and fewer young people are studying technology.

 Any parent of young children will be able to regale you with tales of their offspring multitasking with various devices and apps. The modern, younger generation has grown up only knowing a technology-enabled world and they are a product of that interaction.

 However, that high level of interactivity has not created a rise in interest in the academic side of IT. Just 4,065 students were awarded computing A-levels this year, compared with 4,710 this time last year – a drop of 13.7% (see further reading, below).

 The jury is out on what such developments mean for the UK: while companies continue to offshore certain technology tasks, a core of highly-skilled technicians must exist in the UK. So, how can we get kids interested in the behind-the-scenes coding that supports their multi-tasking lifestyle?

 One possibility comes in the form of Google’s App Inventor, a system that claims to enable non-coders to develop Android software. Instead of writing code, interested individuals visually design the way an app looks and use blocks to specify software behaviour.

 The plus point, at least as far as getting junior programmers on board, is that App Inventor is easy to use. Code is simply snapped together to allow basic events to take place.

 That, however, is also part of the problem. As developers become more adept, the limitations of snapping blocks together – in comparison to being able to write code – become exposed.

 As Darien Graham-Smith concluded in a recent review of App Inventor for PC Pro (see further reading: “Anyone with the programming nous to make full use of App Inventor’s abilities will surely prefer a language that doesn’t force you to pedantically assemble every function, procedure and event out of multicoloured blocks.”

 Google acknowledges App Inventors’ educational route, paying deference to MIT’s Scratch project. But while the system is driven by an educational perspective, it remains restricted by its approach. In fact, Graham-Smith believes App Inventor could actually drive people away from programming unless the Blocks Editor improves.

 The system is, in short, a nice attempt to get people interested in the finer elements of programming. But successful apps are inherently much more complex than pushing Lego together.

Further reading:

 http://www.computerweekly.com/Articles/2010/08/19/242454/A-level-results-mark-39worrying-trend39-for-IT.htm

 http://www.pcpro.co.uk/blogs/2010/09/07/googles-app-inventor/

 http://appinventor.googlelabs.com/about/

AppInventor won’t solve your end user development opportunity

November 29, 2010

Once again, don’t believe the hype. Google recently launched App Inventor, a system that claims to enable non-coders to develop Android software.

The principle is sound enough – instead of writing code, interested individuals visually design the way an app looks and use blocks to specify software behaviour. The open platform for developers, meanwhile, could lead to vast array of specialised apps from people who are traditionally viewed as non-developers (see further reading, below).

However, don’t get the party bunting out just yet. The hype might suggest Google has created end-user computing for Android but the reality is slightly more complex.

Yes, the system allows individuals to work with blocks of code. And the system should be intuitive – it has been in development for more than a year and user testing has been mainly completed in schools (see further reading).

But while the drag-and-drop system of App Inventor is reminiscent of fitting Lego blocks together, experienced reviewers believe the fit is not quite as snug as it could be.

TechCrunch writer Jason Kincaid, for example, has experience of programming and attempted to put together a couple of apps. He concludes that the Google software is far from perfect and is by no means a short cut to back room, smart phone development (see further reading).

App Inventor, then, is a neat, graphical programming tool. The concept is innovative and refreshing. It is not, however, a tool for non-programmers. Google have created another step towards end-user development but this is by no means an end-point.

Senior executives should not be swayed by the hype and should not expect non-technical employees to start creating powerful Android apps. In fact, there is a strong argument for suggesting that the focus should not just be on the creation of new apps.

For some employees, end-user development is a real possibility – and Google’s App Inventor represents another staging post. At the same time, more apps create more maintenance, especially if increasing numbers of non-programmers are really going to get their hands on code.

 Proper end-user development must consider how apps can be maintained without the need for IT to run modifications and changes. Once again, good end-user development comes down to good management.

 End-users can create apps but only if the IT department is able to support such computing easily and cost effectively.

Further reading

 http://mashable.com/2010/07/12/google-app-inventor/

 ttp://www.nytimes.com/2010/07/12/technology/12google.html?_r=2

 http://techcrunch.com/2010/07/12/android-app-inventor-demo/


Digg!

The new legacy is HTML !

November 22, 2010

The legacy of past computing decisions is one of the biggest technology challenges facing businesses. What’s more, lessons from the past are not being heeded.

Let’s start with the most famous legacy code of them all – because if you’ve encountered COBOL, you’ve encountered legacy. Invented in 1959, the object-oriented language became a mainstay of business computing for the next four decades.

The legacy, however, quickly turned into a significant burden. Gartner reported that 80% of the world’s business ran on COBOL in 1997, with more than 200 billion lines of code in existence and an estimated 5 billion lines of new code produced annually (see further reading, below).

The reliance on that rate of production came home to roost towards the end of the last century, when language problems led to the panic associated to Y2K. The story since then has been one of decline. The continued move of business online has led to a clamour for new, sleeker and internet-ready programming languages.

First specified in 1990, HyperText Markup Language (HTML) became the predominant web development language. Its use ran alongside the development of open standards, such as JavaScript and the Cascading Style Sheets of CSS.

Such languages and styles helped to define the layout of the Web. But that is far from the end of the story. Online development in the era of HTML has become increasingly patchy, with more and more developers using varying styles of code.

Additional online tools, such as Silverlight and Flex, create further complexity. The result is that HTML, and an associated collection of standards and tools, are fast becoming the new legacy.

Just as in the case of COBOL, more and more lines of code are being produced. The disparate pace of online development is such that we will end up with reams of legacy HTML, JavaScript and CSS code.

Learn from history and get to grips with the problem now. Make sure you have proper documentation and standards. Select tools that are integrated with the rest of your business processes and which allow users to make the most of earlier development projects.

Think about how certain approaches – such as a mix of HTML/JavaScript and Ajax-server based technologies – will allow your business, and even your end-users, to use the same development techniques on desktop and mobile environments.

Also look to the future and take a look at HTML5, which is currently under development as the next major revision of the HTML standard, including features that previously required third-party plug-ins, such as Flash. Don’t stop there carry on with CSS3, Web Worker and WebFonts all new evolutions of current web technologies that will tomorrow be mainstream.

The end result should be the end of fragmented development and a legacy of useful web applications, rather than unusable and unidentifiable code.
Further reading:

http://www.wired.com/thisdayintech/2010/05/0528cobol-conference/


Digg!

Take your IT department forward by putting end user development at the front

November 19, 2010

Here’s a wake up call for the IT department – end-user computing will definitely become dominant; it’s just a matter of time.

 Proof comes in the form of modern business practices. Increasing numbers of executives are now saying that time to market is absolutely critical. A slow moving organisation is one that loses.

 For many firms, the ability to move quickly is underpinned by technology. The pace of change and centrality of IT to contemporary business means every organisation, whatever the sector, relies on technology to help maintain information flows and to help its employees deal with customers.

 Such reliance should be good news for the traditional technology team. But there’s a significant catch. The business wants to make changes and add products quickly. Technology, as the underpinning structure, should be set up to create speed.

 Unfortunately, this simply is not the case for many businesses.  The integral nature of IT to business processes means that line-of-business executives have to go through IT when they want to make changes.

 In many organisations, the traditional cycle of IT delivery is far too slow. One step forwards – in the form of the business’ recognition of the need to create a new product offering – is often several steps back for the IT department.

 Rather than being able to respond with agility to business need, IT development takes place across an elongated cycle, where each change needs to checked, re-checked and checked again. Businesses, if they are going to be agile, need to stop such lethargy.

 Focus remains on the IT department – and the focus has to be on technology because it is at the core of modern business practice. But smart executives are beginning to ask what can be done so that business change can swerve round the elongated cycle of IT delivery.

 For technology workers, such transformations might seem like a coup d’etat. But there is no need to be scared. IT workers that embrace the change and help the business move towards end-user computing will not be overthrown.

 Your role should be at the higher level, helping the businesses to understand how web interfaces – the new desktop – can be used to help executives avoid the traditional IT cycle of checking and testing.

 Employees want to be able to create instant changes to text that can help inform customers. They want to be able to manage data using their own business rules, creating drop down lists of crucial information.

 Permissions need to be granted and re-granted; workflow needs to be easily manageable, so that the business can use the web to drive agile processes. True agility comes in the form of end-user development.

 And the forward-thinking IT department will recognise it needs to help drive the end-user revolution, not hold it back.


Digg!

RIM = Rich Internet Mobile ?

February 1, 2010

Designing and creating a site for mobile devices is now easy. Rather than relying on a separate and proprietary programming language, developers can create mobile sites using tried and tested technologies from the web.

 Be careful, though. Beyond the promised land of easy roll out lies the potential minefield of poor user experience. To this end, some element of self-restraint is required for companies creating mobile apps. What works on the web using a PC doesn’t automatically translate to the mobile.

 It can be easy to get carried away when designing mobile apps. There’s a temptation to add as many elements as possible, just to ensure all possible customer demands are covered. Reign in your expectations.

 Think of your own use of enterprise applications; how many functions do you actually use? When it comes to standard word processing and spreadsheet tools, do you actually use more than a dozen functions?

 Apply the same logic to your creation of mobile apps and avoid being too rich. Rather than trying to be all things to all users, hone the most important elements that will help ensure a strong customer experience.

 When you have a set of core functions, keep the display simple. Use a basic graphical user interface (GUI), steering clear of complex widgets and graphics.

 An over-complicated GUI – relying on the manipulation of multiple items – will be frustrating to use. It also is unlikely to suit the form and function of the mobile device.

 Keep in mind the limited screen real estate of modern mobile phones. Despite ongoing developments in rollable screen technology (which I blogged about last month), most mobile devices only provide a small display.

 If users only draw upon a limited amount of functionality in their enterprise apps, it’s extremely unlikely they’re going to want more items on a portable device. More to the point, they probably can’t.

 In addition to a limited screen estate, mobile phones are often restricted by their reliance on higher bandwidth. Move to a place with a limited connection and mobile apps can take a considerable amount of time to download or respond.

 With access speeds being so inconsistent, it simply does not make sense to load mobile applications with flashy graphics and interactive features.

 So, avoid being rich and keep you mobile software simple. Rather than overdressing your applications, find an approach that provides high usability. The reward will come in the form of a great customer experience.


Digg!