Archive for the ‘End User Development’ Category

Programming with soldering irons

June 21, 2012

The last time I can remember seeing a programmer with a soldering iron was a long time ago in the hay days of micro computing in the late 70’s. A picture of Steve Wozniak and Steve Jobs in a garage having built the Apple 1 micro-computer. The component parts totalled a few hundred pounds, and the machine sold for $666.66. At this level the cost made this a niche phenomenon, however a handful of very successful entrepreneurs emerged out of this era.

So moving fast forward to 2012, Raspberry PI foundation http://www.raspberrypi.org have launched a $25 computer running Linux, has sockets for Ethernet, HDMI, USB, RCA Video and SD Cards. At this price and capability this is unlikely to be a niche phenomenon, indeed February this year more people were searching for Raspberry PI than they were the world’s most famous pop artist, Lady Gaga ! On launch the interest in Raspberry Pi flooded their website and had to be taken down, and the first batch these was sold out in 1hour.

So is this just about a cheap computer to surf the internet on your TV and to do your basic home computing tasks like word processing on? Well by the time you add a keyboard, mouse and decent memory card the cost will be very close to a low android tablet, so this isn’t the reason to buy one.

The target market for Raspberry Pi Foundation is the education sector where it is hoped these devices will encourage children (11years+) to learn programming which in turn should produce more developers from university. At this cost it is hoped that schools / parents can afford to provide a platform upon which kids will want to learn to program.

However the bulk of the demand I would say will come from techies that want to build low cost solutions that require compute power and software applications. Home automation projects are likely to be popular: creating a solution that allows you to switch lights and other things on/off remotely via the internet. Solutions that require integration with other hardware such as a GPS or camera will also be popular.

Already projects looking to create their own weather balloons, remote controlled robots, music studios and many more have started ahead of people actually having the kit in their hands. So you can see more idea’s here http://www.raspberrypi.org/forum/projects-and-collaboration-general/the-projects-list-look-here-for-some-ideas .

It is early days but to me it’s obvious the options and therefore opportunities for innovation are going to be huge, some will be very practical, some will be fun (for example the guy that created a device that allows him to feed his dog via the internet, some will be useless but in all there will be lots of new ideas using these devices in the coming years.

The next Steve Jobs, Mark Zuckerberg or Bill Gates is amongst our children already so the time is right to get in the queue for your piece of Raspberry Pi.

Click, touch, wave and talk: UI of the future

May 10, 2012

First there was the Character User Interface (CUI, pronounced cooo-eey) typified by green letters on a black background screen. Then the Graphical User Interface (GUI, pronounced goo-eey) came along with a mouse and icons. Pen interfaces existed in the era of GUI, but now smartphones and tablets are driving many more interaction approaches using touch interfaces.

Now the GUI itself is going through a re-birth on mobile platforms with many more new types of user interface controls than we have seen in the past, we have gone way beyond simple buttons, drop-down lists and edit fields.

Many devices also support the ability to support voice driven operations, and although voice recognition has been around for over two decades, the experience is poor and more recently drastically oversold by the likes of Apple. However this is an area that will is likely to improve radically in the coming years.

The Microsoft Kinnect gaming platform provides yet another innovation in user interaction, a touchless interface using a camera to recognise gestures and movement. Microsoft are already making moves to take this form of user interaction into the mainstream outside of gaming (http://www.bbc.co.uk/news/technology-16836031), as are many other suppliers and we should see phones and TV’s supporting these this year.

However even some old methods of interaction are being given a new lease of life such as Sony’s inclusion of a rear touchpad and dual joysticks.

So, with all these modes of interaction what does this mean to User Interface Designers? Shouldn’t they really be called User Interaction Designers? How do you decide what is the best mode of interaction for an application? Should you support multiple modes of interaction? Should you use different widgets for different interaction? Should the user choose their preferred mode of interaction and the application respond accordingly? Should the mode of interaction be decided by what the device supports? Are there standards for ALL these modes of interaction?

This emerging complexity of different user interaction methods will raise many more questions than I’ve listed above. So far I have only found little research in this area, but this is a moving target. The other evidence from the mobile world is the rapid change in user behaviour as users get used to working in different ways.

Initially I would imagine most applications to use basic interactions like touch/click so that the widest possible range of devices can be used. However those targeting specific devices will be the “early adopters” for the common interaction mode for that specific device (e.g. 3D gestures on Xbox Kinnect).

In the very long term standards will evolve and interaction designers and usability experts will combine to design compelling new applications that are “multi-interactive”, choosing the most appropriate interaction method for each action and sometimes supporting multiple types of interaction methods for a single action.

Multi-interactive interfaces will make users lives easier, but are you ready to provide them?

HTML5: The right time right place for mobile?

February 9, 2012

Most people by now understand that main challenge for developing mobile applications is creating a solution that runs on as many platforms as possible. This challenge can range from supporting browsers that only support text, up to fully fledged smartphones.

For organisations that are targeting users in the developed world, many are simplifying this challenge to target smartphones only. However even here to create local native applications requires solutions that support Apple’s iOS, Windows, Android and Java (Blackberry).

There are many mobile development platforms available to assist with creating “write once deploy everywhere” apps. The main constrains here are that you end up with deployments to many different stores, and that quite often still write platform specific code to take advantage of platform specific features.

HTML5 has long been a strong candidate for mobile applications, but is it ready? Are mobile browsers upto date with HTML5?

The answer to this question can be a simple “No”, no mobile browser supports the full HTML5 specification. Or a “Maybe” depending on what features (camera, phone book and GPS) of the phone you require you may have support from HTML5.

Push that up to a resounding “Yes”, if you want to move an application that currently runs on the web to run on mobile. Of course, I should also caveat the above with ‘there are grey areas’ in between these responses, not very helpful I know.

For corporates looking to support mobile users with line of business applications I believe there are some great examples that prove HTML5 is ready for them. For a start Facebook is one such application taking full advantage of HTML5, and promoting its use for Facebook apps.

The key areas of HTML5 that are supported across mainstream mobile browsers are offline storage, geolocation, multimedia, graphics (canvas), touch events and large parts of CSS3. The mobile HTML5 site provides a list of mobile browser capabilities.

In the past marketers are argued that presence on App Stores adds value to “brand awareness”, and whilst this is true, there is nothing stopping an organisation having using both native apps and HTML. For example, take LloydsTSB. You can download their app, which effectively once downloaded then runs a “browser” version of their Internet banking service.

There are also some great libraries out there that make cross platform mobile development much easier and provide features that make your web applications feel much more like a native phone app. JQueryMobile is a great example.

So what are you waiting for?

HTML 5 makes the browser smarter

January 26, 2012

The unsung hero of the web has always been Javascript, without which the standards-based web would be completely static. Javascript enables functionality to be executed in the browser, and has been used to create all sorts of effects otherwise not possible with HTML alone.

In the early days, Javascript implementations weren’t entirely standard, requiring developers to have to write variants for different browsers; this isn’t really an issue any more.

For applications, developers will either use libraries or develop their own validation routines. This Javascript code adds significantly to the amount of code downloaded.

With HTML5, developers will need to write less Javascript, as the browser provides features to do things for itself rather than rely extra scripting.

Validation is the main area of improvement. HTML5 now provides a number of new validation features such as mandatory checking, type checking, range and field length validation. The validation is done within the browser, and developers can opt to decide how to process errors.

Obviously validation has to be repeated on the server for security, to ensure that data hasn’t been hacked in the browser or in transmission. This then means that validation has to be maintained in two places and kept in sync.

HTML5 also provides a number of new input field types such as tel, email, color, datetime. This empowers the browser, by applying it to display a date picker, or a colour chooser for example. More importantly for mobile applications it would allow the browser to show an appropriate keyboard layout e.g. a numeric layout for tel, and an alphabetic keyboard for email type.

There are also a number of new attributes which previously required Javascript such as autocomplete, placeholder and pattern which will prove very useful.

There will be some organisations that will not want the browser to affect their carefully designed user experience; for these people the answer is simple, just don’t use the new features.

For the rest, you will enjoy having to write less Javascript for HTML5 browsers, but of course you will still need to have backwards compatibility for non-HTML5 browsers which will rely on Javascript.

HTML5 Gets pushy

January 20, 2012

In the past there have been a number of clever approaches to get around the limitations of web technologies inability to allow servers to broadcast messages/data to clients. One of the more popular libraries for such capability has been Comet.

Whilst providing a solution where the standard lacked functionality, Comet is quite inefficient – both in terms of network bandwidth and performance.

Comet effectively posts a message to the server and the server replies if there is data waiting to go, if there is not the call is left waiting and if subsequently it times out the client is notified which in turn then makes another call. So it’s inefficiency is that it is constantly making calls to the server regardless of whether there is data to be sent back or not. Also it is using HTTP, so the requests are relatively large in size.

In a previous blog, I mentioned how the WebSockets API allows you to have bi-directional messaging between a browser and server. The use of WebSockets requires a Socket server to facilitate messaging using the socket protocol (which is far more efficient in terms of request size than HTTP). The most popular example of a good use of WebSockets is online chat.

However there is another option: Server Sent Events (SSE).

The main advantage of SSE is that no additional software is required, a standard web server can be used as it only relies on the HTTP protocol. However, the main downsides therefore are that SSE is uni-directional, server to client broadcast only and, because they use the HTTP protocol, the message requests are much larger than socket calls.

SSE also allows arbitrary events which even allows messages to be sent to different domains. Care needs to be taken as this can be open to abuse, so developers should check the domain from which the event has been generated is one that they are expecting.

This is a powerful capability, and for anyone looking at “lean portal” implementations, could be a way of creating functionality like “inter-portlet communication” without requiring a portal server to facilitate the sharing of data.

They are also relatively simple to implement which again gives them an advantage over WebSockets.

SSE will be most useful to applications like stock ticker’s, live news, weather updates, sports scores and any other applications where the server needs to push data to a client. So does this mean the end of Comet? No because to provide backwards compatibility with non-HTML5 browsers, Comet could be used as a polyfill.

The BBC does a U turn on HTML5

October 12, 2011

Rewind to August 13th 2010 and Erik Huggers Director of BBC Future and Technology blogged that the the BBC were committed to open standards but “HTML5 is starting to sail off course”.

At the time I thought this was a brave statement to make especially as the late Steve Jobs had already announced in April that year and despite a billion app downloads, that HTML5 negated the need for many proprietary browser plug-ins. It was clear at the time this was squared largely at Flash (and possibly Silverlight too).

For me this was a faux pas too far as Huggers continued his blog with statements about proprietary implementations of HTML5 by Apple and fractions of opinions within the W3C and WHAT-WG (who initiated the development of HTML5).

Now fast forward to almost exactly a year later, and Gideon Summerrfield, Executive Product Manager for BBC iPlayer announces the launch of a HTML5 version of iPlayer. Initially this is just aimed at PS3, but will roll out to other devices in the future.

If we take a slight diversion and look at the developer conferences for both Microsoft and Adobe in the last four weeks, both made big announcements about tools and support for HTML5. However committed developers with years of invested skills in SilverLight and Flash were left deflated with the lack of announcements on the future of these technologies.

So have the sleeping giants finally woke up? It seems like it to me.

However, in the case of the BBC, Summerfield’s blog states that they will also launch new versions of the iPlayer for Flash and Air. This may be a short term decision to wait for wider support for HTML5, but there is little clarity about what they see as the future for iPlayer.

To Hugger’s credit he did foresee the benefits of HTML5 could bring to the BBC in reducing development timescales and having a common skill set.

However I applaud those that have the courage and conviction to take bold steps forward and put their money where their mouth is. The FT is a shining example, ditching their AppStore versions for iDevices and completely moving to HTML5.

There is work to be done on HTML5 and it will evolve for some time yet, but the bandwagon has started to roll and as a good friend of mine said to me at the start of the .com era, “When you see the bandwagon starting to move, you have a choice to jump on, or stand in the way of a tonne of metal !”.

For me it is clear. I’m not standing in the middle of the road, I’m jumping squarely onto the HTML 5 bandwagon. The question is, are you?

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!

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!

Can End User Development solve the standards puzzle?

November 15, 2010

Have you tried developing for the web recently? Did you find the broad range of forms, formats and requirements to be helpful or a hindrance?

 The chances are that you fell into the second camp; any IT specialist dabbling their programming hands in the complicated world of the web is likely to be left feeling frustrated. There are, quite simply, too many standards – and the only way out is end user development.

 Without standards, web development is a mess. Programmers in different parts of the business create a series of different platforms, preventing integration and creating specific point solutions.

 Where those solutions work, problems are hidden. But when the business tries to bring together and consolidate existing developments, IT specialists are left with an almost impossible migration effort.

 Lack of standards mean coders are left with an incomplete puzzle of different approaches to web development. Trying to establish order in such a fragmented world is very, very tough.

 Help should come in the form of cross-platform integration, such as Representational State Transfer (REST) and Simple Object Access Protocol (SOAP). But concerns arise there, too.

 As Jeff Vroom suggests in his recent excellent article for The Register (see further reading, below): “I haven’t found one platform that offers all features in a portable, open way that would gather enough momentum to establish standards.”

 Don’t look to the big vendors, either. Vroom – like many other commentators – believes the big players are unlikely to prevent fragmentation by the removal of extra frameworks that can be used to create more expensive, but more complex, standard platforms.

 Options need to be cut; formats need to be reduced and code needs to be easily re-used. So, what is the answer? Most likely – and as I have suggested a number of times – end user development (EUD).

 We need to give power to the people in the business, allowing end users to create tools from their desktop. EUD can help cut costs and boost efficiencies across a wide range of technology areas, such as web design, collaboration and modelling.

 The user knows what they want to achieve. We should give them the framework independent-means to achieve that objective. End user development really is a means to slashing the amount of forms and formats.

Further reading

 http://www.theregister.co.uk/2010/06/14/vroom_forms/


Digg!