Island Web Works

Cards on the table, I [personally] am not an Apple fan. That is not to say they haven’t had some amazing success with their iPhone/iPad products. The smart-phone market really needed that charismatic device to give it a boost and Apple seem to have achieved this very well.

Smart-phones are phones that try to provide much of the functionality your laptop or desktop does, but in a mobile footprint. With features such as emailing on the go, synchronising with your desk-bound computer’s contacts or playing games for time-suckage they were very definitely a niche market for power-users and geeky-types. They were never really easy to use, and industry politics fragmented the market just as much as they did with the browser wars of the 90’s. If you were a Microsoft user, you’d use Windows Mobile, if you were in Europe, you’d remain loyal to Nokia and if you were a business user, you’d use BlackBerry.

Apart from the trickiness in setting up their internet with your network provider, internet access was difficult. Browsing web-sites on mobile devices was not a very enjoyable experience. Web site developers didn’t think (or care) that people would access their site on a mobile device, with a 3inch screen, so didn’t put the thought into how their site should behave. What resulted is a mess for both the web-site and web-browser. The web-browser would try to accommodate the developer’s shortcomings and try to make sites work, often by mimicking a desktop browser interface. Zooming pages down, resizing pages, etc. were some of the techniques which, in my opinion, were wrongly used to fix what was essentially a problem of the web developer. In much the same way, Internet Explorer can often be a horrendous development experience because of the little “fixes” added to the browser to overcome deficiencies in the web-site mark-up.

Since the Apple iPhone, web-sites have started to do things how they should be done … properly. When developing a site, some consideration should be made for alternative platforms (mobile phone, tablet, projection, television) and sites are approaching this using one of two techniques:

• Developing their site according to web standards and mobile-aware stylesheets. Therefore, a mobile user sees the same site as a desktop user, but with an optimised layout. This is the preferred method.
• Developing a specific web-site for the mobile interface. This essentially doubles the work, but can result in a more optimised experience though confusion between two essentially different web URLs may result. This is a method employed by the BBC, Twitter and Facebook, all complex sites so reducing the “noise” (and therefore data charges).

The down-side of the Apple iPhone/iPad/i* model is the concept of the “app”. An App is an application that fulfils a discrete function, and tends to be small, cheap and easy to install for the user. Brilliant idea.

This is where I must be missing the point.

Apps are essentially proprietary. If you have an Apple device, you can only use apps on the Apple app-store. If you have an Android, you can’t access the apps on the Apple app-store, due only to the developer’s decision - which may be due to resource, device accessibility, preference or ability. The user suffers. A web-page (maybe an “HTML5 app“) is accessible by all.

Apps are difficult to update. If an app is released and a security hole is identified, or a bug found that requires urgent attention, it becomes difficult to “push” that update out to the users. The app becomes subject to the politics and workflow associated with its respective store. In the case of the Apple App store, updates are particularly difficult to deploy, even for minor fixes. Issuing a fix on a web-page is done exactly once and is visible to all instantly. Users suffer with bugs.

Apps require wider skill-sets. Developing apps requires a programmer able to access the development skills and resources of the target device. For Apple, it’s Objective-C, for Windows Phone, Silverlight and .NET, for Android it’s Java. These tools are essentially free, but for how long and how much did it cost to train up that programmer? Users suffer if the developer isn’t completely “clued-up”, businesses have to pay for same functionality many times.

Apps are political. The politics behind the respective app-store for the device will ultimately define your user experience, the delivery of your app and your ability to effectively support your users. Politics and the freedom app-stores create for developers range from the “open” Android store to the dictatorial Apple store. “Thou shalt not use any environment other than Objective-C” meaning iPhones can’t access Flash or Silverlight content. (Though Apple are not alone in this restriction.) Users suffer due to missing content. Income streams may be wiped out, overnight.

Many apps require internet access for functionality to be available, and there are many examples of this. The BBC iPhone/iPad app - isn’t that just sucking in an RSS feed? Facebook for iPhone - again, just using an internet data-source and rendering content? There is surely no need for these apps? Why isn’t a web-page sufficient, particularly as both sites have dedicated mobile sites. The only reason why I would imagine that they would need an “app” would be for offline access, a “cache content and look later” model - but HTML5 defines a standard for local file storage which is implemented on iPhone which would achieve this.

Perhaps the app offers an improved user experience using the native user-interface API, but that itself is not a strong enough reason. If the user is browsing using an iPhone, use an iPhone skinned CSS stylesheet, likewise for Windows Phone, etc. If it’s accessibility of the web-site that’s the issue, the phone OS should allow bookmarks of sites to become first-class citizens within the OS user experience. Windows Phone 7 does this excellently with pinnable “tiles” representing bookmarked sites on the Start screen. Thumbnails instantly identify the purpose of the site.

For me, the only reason an application should be developed is if the functionality is not available within a web browser. And that would be access to local resources or OS features. The Facebook for BlackBerry application integrates with the phone’s Contacts application to allow access to Facebook profiles, for example. This would clearly not be possible from within a web-browser but offers a seamless user experience. Facebook for Windows Phone 7 is similarly a first-class citizen within the phone itself, though not via an “app”.

So what explains this tendency for every site to reproduce identical functionality and content to the original web-site? I can only think that “sex sells”. The “there’s an App for that” model is seen to be sexy, cool and easy to use. Few companies are as guilty of over-marketing the banal and simple as Apple, and they have achieved it right here. They have developed an eco-system, a culture and a platform that stifles innovation, widens the gap between the developer and the user and acts anti-competitively towards key rivals. I remember another company getting its hands very publicly slapped for similar practices, but Microsoft just weren’t “sexy” enough.

Nathan Articles Android, Apple, iPad, iPhone, User Experience (UX), Windows Phone 7

World politics and web design are two unlikely bed-fellows, but if you have used a web-form with a list of countries, or are living in a “semi-recognised” country (for example, The Isle of Man), you will appreciate the issues. Add to the equation the complications of postage, taxes, sanctions and embargos and it can get quite complicated.

Defining countries can be a sensitive issue, with some countries not being recognised by others and local usages and naming styles also causing problems. That is why we lean towards the formal when we work with lists of countries. We use accepted international standards as a source for our lists, which allows us to take a widely accepted view of country names around the world, hopefully without causing offence.

This list presents us with problems, however. Consider the screenshot below from a list of countries for a large site we are currently working on:

'Leaking' drop down list with wide country names

The first problem is the large amount of horizontal space used by the entries, which causes the drop down list to be expanded artifically. This makes it difficult to fit in some designs. This is highlighted by the purple arrow. This width is determined automatically by the longest entry in the list, in this case “MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF”. Far be it from us to assert our right to change a country’s name, we need to hit a compromise. This can either be changing the design to accommodate the wider data or - at a last resort - changing the data (in this case, we could use the commonly accepted “FYR” abbreviation).

I was asked why all the countries are in capitals. “Well, that’s how they come in from the original standard”, I replied. The thing is, capitals require wider horizontal space and it does feel like you’re shouting. I imagine the ISO standard is capitalised to avoid another thorny issue; what exactly should be capitalised in a country name? While “Macedonia, The former Yogoslav republic of” may be technically correct, it may not be politically correct. We decided to stay with the CAPS. Another reason to stick with the CAPS is because users are traditionally used to seeing country lists in capitals. When was the last time you entered your country and it was lower-case? By retaining capitals, we build on this albeit uncomfortable convention.

Semi-recognised Countries and transient states are also difficult to navigate. The world is constantly changing and countries are born, extinguished and forgotten even in modern politics. On The Isle of Man, we are in a position that is little understood away from its shores. While we are a crown dependency, and a country, we are not regarded as a sovereign state. So, we tend to be lumped into “United Kingdom”, even though technically, we’re not actually in the UK. Web users on the Isle of Man have become used to going for “United Kingdom”, as opposed for hunting down the Isle of Man within the “I”s.

I remember this being particularly contentious when I was working for an e-Commerce web-site provider. While we should provide “Isle of Man” as a country option for reasons of correctness, postage, etc., we couldn’t rely on that data being correct because Isle of Man users may just be used to using “United Kingdom”. If we avoid including “Isle of Man” from the selection, we might have incorrect data, but at least it isn’t inconsistent.

It can be a minefield, as you are always keen to avoid offending your users at the very least in trying to create a positive web experience. It’s also important to lean towards convention when designing user experiences, as your experience is only one in hundreds that may have used and millions on the wider internet.

Nathan Web Site Development User Experience (UX), Web Design

This post is part of a MIGTurbo CRM 2 series that will highlight the key improvements and features in the new product that we’ll be running over the next few months. You can also follow our Twitter account @migturbo for regular updates on progress.

When we blogged about the new client/server model of MIGTurbo CRM 2, we gave a hint as to how we see users interacting with the product. This post discussed how the database server was “hidden” behind the MIGTurbo application server. But if the user cannot connect to the MIGTurbo database directly, how can they use MIGTurbo?

MIGTurbo CRM 2 brings with it a comprehensive API for extending the product both at the server level, and at the client-level. Using this API, we can provide secure access to MIGTurbo data using nothing more than a server URI, a username and a password. We’re going to include two “clients” out of the box.

MIGTurbo CRM 2.0 Silverlight Client

The MIGTurbo CRM product demands a rich user interface that is a pleasure to use, as it is often the key component on a user’s desktop. We were keen on retaining a web user interface, but we didn’t want to find ourselves working around the complexities of web pages and utilitising toolkits that were stretching the web experience to its limit. We developed a number of mock-ups using web page-based user interfaces but felt that we still lacked the killer customisation and user-driven experience we required. Until we created a mock-up in Microsoft Silverlight.

Microsoft Silverlight is a rich internet application (RIA) platform that allows development of web experiences that combines the mashing together of web data and technologies and a rich user experience. While it is implemented in much the same way as Adobe Flash, it is actually a richer and more comprehensive platform. Silverlight brings with it a subset of the .NET Framework, building on existing APIs such as WCF and WPF. Much of the code between server and client can be shared, and using the Microsoft stack, we were able to create an attractive and extensible user interface on business data. We’ve remained loyal to our user interface, too, as you’ll see in upcoming screenshots.

Using Silverlight, it is also possible to “install” MIGTurbo locally. This “out of browser” experience creates an icon in your Start Menu that behaves in most ways as if the software was installed locally on your own machine. This reduces the gap to the server, but it is important to note that MIGTurbo will continue to run in all the major browsers on the Windows platform (Microsoft Internet Explorer, Mozilla Firefox, etc.) and also the Apple Mac platform.

Silverlight remains amongst the most secure application platforms available on the internet today. It also is not standing still. The upcoming release of Silverlight 4 promises interoperability with desktop applications, webcams and more. Rumours abound of Silverlight appearing on mobile devices being announced in the MIX10 event from the newly rebranded Windows Phone to Symbian devices. If you’re in doubt, check these trends out for people investigating Silverlight as opposed to ASP.NET on Google.

MIGTurbo CRM 2.0 Office Client

Not all users will need to use MIGTurbo for their day-to-day work. And not all users work in a web browser silo to fulfil their function. That is why MIGTurbo CRM 2.0 will extend the successful Outlook Toolbar add-on to provide more functionality direct from Microsoft Office.

Users of our Outlook Toolbar have seen how integrating with MIGTurbo and MIGTurbo DocuMentor has made their job dealing with items in their inbox much easier, especially when relating communication back to clients, respondants and candidates. We’re building on this functionality to dig deeper into MIGTurbo, providing features from across the product including any plug-ins. The MIGTurbo toolbar will appear in Microsoft Outlook and will also soon appear in Microsoft Word and Excel. You won’t be far from MIGTurbo, whatever your role may be.

This is possible using the MIGTurbo CRM 2 API. We’re already starting to hear expressions of interest on how our clients can utilise this API for themselves to extend our existing user interfaces and build entirely new ones for their own specific purposes. The API is secure and uses the Microsoft stack so will be readily portable onto desktop, web and portable devices.

These posts discuss features of MIGTurbo CRM 2. While we have every confidence that these features will appear and work as discussed, these blog posts do not represent a final product specification. We will release final product specifications at launch.

Nathan MIGTurbo CRM 2 MIGTurbo 2.0, MIGTurbo Outlook Toolbar, Silverlight, User Experience (UX)

With the new user interface in MIGTurbo 2 coming together, we were faced with the daunting task of replacing the existing set of icons.  In older versions of MIGTurbo we have been using pixel-based 16×16px icons, just like the ones you find in older versions of Windows (pre-XP).  Whilst they’ve been serving us well, we thought a new set of vector-based icons would suit the new Graphical User Interface (GUI) better.

So, considering we’re currently using more than 350 icons in MIGTurbo, how to go about getting a replacement set?

First we looked at commercially available icon libraries, but we soon hit a couple of problems. To start with, existing libraries are subject to a range of complicated licence schemes, where you might or might not be able to use the purchased icons in distributable software products (whilst it’s true that MIGTurbo is a web based solution, it’s not after all a single hosted web site).  Secondly, finding a set of icons in a suitable style catering for our rather specific needs proved to be difficult.

In the end we found it more convenient to create the replacement set ourselves.  This gave us full control to add and/or modify icons to suit our needs, and obviously licencing wouldn’t be an issue either! Also, it was quite rewarding to get an opportunity to work in Illustrator again.

So, what at first seemed to be a daunting prospect turned out to be the easiest solution - with the added bonus of getting a unique one-of-the-kind icon set!

Below you can view a small subset of the new icons - I think they turned out quite well!

Andreas MIGTurbo Graphical User Interface (GUI), GUI, icons, MIGTurbo, MIGTurbo 2.0, User Experience (UX)

You may recall we’ve been working on improving the speed of MIGTurbo 2.0 further by making various optimisations in the call to the server and its response to the client (your web browser). Having set the precedent and the model to use, this work continues.

Our new Security Editor for MIGTurbo 2.0 builds on our existing security mechanism in MIGTurbo 1.8 and 1.9 by introducing Roles and Rules. Without going into too much detail at this stage, this will provide users with an elegant and flexible solution for securing their system, whether they prefer MIGTurbo “locked down” or with more liberal access. The customer decides, not the software.

It’s important we get the user interface for this right, as it is a new concept and we need to be sure that users can jump on board with the new flexibility this offers. If you’ve used Windows file permissions, you’ll quickly become au fait with the new interface. 

Using the same technique, by using AJAX and web services to circumvent the traditional web page processing pipeline, interaction times were cut again. In fact, moving rules up and down the list occured so fast you couldn’t be sure if it had actually happened. Using AJAX means that we can update the page seamlessly, so can change small elements of the page with no-one but the most eagle-eyed users noticing. Using web services, we can do it faster. 

This presented us with a problem. We actually needed to slow down the interface to provide the user the reassurance that something had actually happened. We’ve come up with a nice visual cue that takes 0.5 seconds to run through, but gives the user the confidence that something has actually occured.

Take a look at the first screenshot from MIGTurbo 2.0, albeit a very small one (we don’t want to give too much away just yet!)

I’ve just clicked the “Up” button to move the UserAdministration rule above the rule above it (thereby allowing UserAdministration members to perform this particular action). Instead of simple redrawing the rules, the rule “fades out” and then redraws. This gives a small and simple visual cue that something is happening. 

Another effect we’re working on is when deleting rules. In the same example, if I was to delete the rule by clicking the Delete icon, the rule is turned red, then faded out. This gives the impression that the rule has been “blown up”. Another simple cue that confirms something has happened without requiring any interaction or confirmation by the user.

We hope to add more of these interstitials to reinforce the actions that the user is performing within MIGTurbo 2.0. They don’t just provide a key aspect of a user experience, though, they also make the use of the product a little bit more fun (but don’t “blow up” too many things)!

Nathan MIGTurbo MIGTurbo 2.0, User Experience (UX)

Following on from Nathan’s last post, the question that springs to mind is Why Bother! The reason, in a single word is ‘Confidence’, if you lose the clients confidence you have lost the war. Regardless of the label you assign a business like ours, we develop software. Business software, productivity software, CRM software, the label is secondary to the fact we build software solutions, and part of the solution is a product that works. If a product is slow and laboured, it may be the most functional, secure, useable product on the market, however, all you will hear from users is ‘it’s slow’.  And they would be right!  Clients need to be confident that the investment they have made actually improves productivity and slow systems don’t tend to inspire that confidence.

The largest cost to most businesses today is labour and a slow network, PC, or software application is costing you money, every single hour of each and every day it is in use.

If a computer operator regularly waits for their PC to process instructions, you could easily be losing 20 - 50% (or more) productivity per staff member. This means that in order to support a 50% growth in business you will need to either increase staff by 50% or increase productivity by 50%, and one of the simplest ways of improving productivity is to use the correct tools for the job.

When it comes to Business productivity - faster is usually better!

Charles MIGTurbo User Experience (UX)

It’s been a tough couple of days on the MIGTurbo CRM 2.0 project. I’ve been working on the code to Display and Edit Client Details. It’s nothing spectacularly complex or detailed, of course, but there was a niggling issue that was bugging me.

MIGTurbo 1.8 /1.9 is fast, very fast. So in writing next-generation code to replicate the functionality and speed users are used to, we need to make sure that we can maintain a similar level of user expectation. As with the commitment to maintain the User Experience in terms of user-interface, we also need to make sure users’ expectations of speed is maintained.

Traditionally, when editing a record on a web application, there is the inherent cost of applying the changes to the server, retrieving the latest details and updating the user interface. All quite costly. In the slowest tests performed in the last couple of days, this was taking up to 5 seconds. A lot of debug code, and support resources are involved here and this does not represents a “real-world” scenario, but even 2-3 seconds will give a feeling of “lag”.

Improving the speed of this was very important, and if we could do it using the same foundations we’re implementing for improving extensibility, then all the better. So, armed with acronyms and search terms, I set upon resolving the speed issue and tweaking the code to extract every bit of performance possible. Effectively, this has taken 2 days … to gain 4 seconds of performance. Now, a typical round trip takes less than half a second (in rough tests).

Was it worth it? Of course it was. Those 4 seconds, multipled by all our clients, multiplied by the number of times a user performs that single function and you get a significant time difference that exceeds 2 days. What would have taken a round trip of approximately 30Kb (even using AJAX - albeit ASP.NET AJAX) now takes a round trip of less than 200 bytes in a typical scenario. That’s a lot of bandwidth given back to the network and it all goes to ensuring MIGTurbo 2.0 remains an enterprise class CRM.

Just in time for the live streaming of The Gu’s Keynote at MIX09 and all without a Diet Coke, too.

Nathan MIGTurbo MIGTurbo 1.9, MIGTurbo 2.0, User Experience (UX)

Charles recently blogged about the challenges around making improvements to established products and designs. MIGTurbo is a successful CRM package and is evangelised and valued by its users. One of the reasons behind this, we believe, is the supremely simple and quick user interface. We are currently internally testing the next version, MIGTurbo 1.9, and this has a number of exciting new features which will further enhance the user experience - or ‘UX‘ to its friends.

So when moving towards the next major milestone in the MIGTurbo roadmap, MIGTurbo 2.0, it presents a challenge to us. While we are looking forward to being able to provide more features and better performance with a contemporary design, we must balance that with what we know has made the product such a success up until now … and that is the simplicity of the user-experience.

One thing I have really appreciated since joining Island Web Works is the opportunity for frank discussions about everything from the fundamentals of the Microsoft SQL Server Paging mechanism to the finer details of Natural Selection. These discussions have allowed me to come into the business as a new member of the team and also as a new and fresh user of the MIGTurbo application while still being able to contribute my opinions and outlandish statements without fear of tarnishing any egos. So when looking at what form the user experience of the 2.0 release should take, a full and frank discussion could be had. 

We quickly identified and agreed that we did not want to repeat Microsoft’s mistake with the Office 2007 user interface. Previous users of Office 2003 were able to use their years of experience using the world’s most popular office suite to create and manage their documents, spreadsheets and presentations with relative ease. Ever since Word 6.0, the user interface has been more or less consistent even as new features were added. Then, in 2007, Microsoft redesigned the entire user interface of the Word, Excel, Access and Powerpoint products to use ‘Ribbons’. Sure, the Ribbons are beautiful, and I happen to prefer them, but most users just want to get the job done and when functions not only move but appear to disappear altogether, user unrest is sure to follow. So despite extensive usability testing and user experience workflow modelling when coming up with the Ribbon Experience, users are still rejecting the user interface due to requirements of loss of productivity and requirement of re-training staff. While we need to maintain a consistent experience with previous versions, one of the key components of the MIGTurbo 2.0 roadmap is extensibility, so we equally didn’t want to restrict any opportunities in the future. We need to be able to provide extra functionality, in new places, but not disturb the central usage workflow.

Our challenge is how to maintain a consistent user experience for those users who have used the product for years, while providing visible opportunities to help them get more out of their usage of the product - but at the user’s own pace. We are working on an experience which will mirror our existing UI design and associated benefits, but will also hint at opportunities to help users focus on the job in hand. One key example I use is a month-end procedure. We want to be able to facilitate everyday use whilst accommodating specialised use, so provide the regular “everyday view” but give enough cues to help the user realise that they can extend their view on the system to perform specialised procedures even easier than before. This did not happen with Office 2007.

After the discussions we have had both today and previously, I believe we have come up with a sensible compromise. We will be maintaining the experience as much as possible for users who are already used to the system by ensuring functions and data are where they always were. There won’t be any disappearing or moved functions, but there will be additional opportunities to get more from the user experience. We will achieve this by mirroring established design patterns that have proved to work. By adopting patterns such as the Task Bar, Breadcrumbs and Menu patterns along with Web 2.0 practices, we can benefit from existing user experience. When a new user uses the new MIGTurbo for the first time, they will already know how to use the menus, how to navigate between screens and why the application feels the way it does because they will have already used the techniques in other applications. When an existing user uses MIGTurbo 2.0, they’ll have a strong degree of familiarity based on their previous experience.

It’s too early to show screenshots as the UI framework that will hold the functionality, data and plug-ins together is still very much in flux. However, we are looking forward to involving users in the latter stages of the development of the user experience to further build on our impressions and experience using MIGTurbo and seeing other users use it, both the user and the seasoned expert. This will provide us with a valuable opportunity to see user reactions at first hand and give users a valuable opportunity to further influence the design of a product many users spend all of their office day with.

Nathan MIGTurbo MIGTurbo 1.9, MIGTurbo 2.0, Office 2007, User Experience (UX)