Archive for the ‘Custom Technology’ Category

9 Reasons to Use Website Animation in your Web Application or Website (and when not to)

April 26th, 2022 by Jimmy Bui

Website Animation

“Website animation” refers to movement of content onscreen, but is distinguished from video / movie content.

There are many useful applications for animation in your website or web application.  Some of the most common animations you will see in modern websites and web applications include:

ACTIVITY INDICATORS

Waiting for a screen to refresh after submitting information is bad enough, but when there is no indicator that something is happening, people get nervous!  The spinning icon that appears in the middle of the screen gives you just enough visual indicator that something is happening, to remove the temptation to click again, just to make sure something is happening.  🙂
Loading animation

Whilst tempting to fill the page with them, that’s the last animation we will actually embed in this post!

Interactive forms

When you click in a form field, and a set of instructions slides into view to help you fill out that field.  Showing (and then rapidly hiding) each keystroke as you enter your password uses animation to help you get your password right, without letting others easily see it.

There are many ways that animation of form elements is used to guide a person to complete a form, including on-the-fly error handling.

Photo SlideShows

Communicating key messages to your audience in the one area of the screen is often achieved via an image & message “slide show” at the top of a website home page.  The home page slider uses movement and visuals in a defined area of the screen to quickly convey information, and attract attention, without the visitor needing to scroll.

Animated Graphics

For example, a logo that draws the attention of the viewer as it “forms” in front of your eyes will help your audience remember your name and branding.  We have assisted clients recently with animated logos as intros / outros for webinar presentations.

Animated graphics are also used to delight the viewer, or make a big impact, for example the animation at the top of the Enudge website.

Animation is often used to help communicate concepts, and is widely found in online learning to emulate a physical educator, and/or visually teach the viewer.  The quiz / card game “Know Lupus” is a great example of the use of animation to educate.

Simulation can be greatly enhanced through the use of animation.  We used animation within a desktop application which helps a user of a centrifuge simulate the movement of liquid through the centrifuge.

The animation at the top of the Contactpoint website is another example of the use of animated graphics, which tells a story to help a visitor understand the types of technologies we work on.

The transitioning text at the top of the Kool Kidz Childcare website is another example of animation to communicate a key message, in a fun and eye-catching way.

What is JavaScript?

JavaScript is a scripting language which used to create and control dynamic website content on both client-side (that is, the content that the person using the web browser sees, and that is located on the visitor’s computer) and server-side (that is, the content that can be programmatically generated in reference to databases and other assets).  Dynamic content allows us to create highly interactive web pages and web applications.

JavaScript is the most common technology for achieving onscreen animation within websites and web applications.

There are numerous common JavaScript frameworks which are used by many web programmers, including:

  • jQuery
  • Vuejs
  • React
  • Nodejs

Each of these frameworks have JavaScript as their base, over top of which they provide numerous packages.  These often comprise:

  • A more succinct or more understandable programming syntax. It’s all still Javascript, but each of the common libraries mentioned above look very different from each other, to the programmer.
  • A collection of tools that achieve specific user interface tasks. That could be anything from common user interface components (such as forms, sliders, carousels etc), security components, data manipulation components, and more.

Some technology solutions require the use of more than one JavaScript framework, or additional JavaScript libraries that have a very specific purpose.  For example, when building a web application which has clear separation between backend processing and frontend design, we will likely use Vuejs for the frontend (client-side) aspects, and Nodejs for backend (server-side) processing.

For very complicated animation, developers may also use additional JavaScript libraries, which make animation easier and more convenient to achieve. The top 5 JavaScript animation libraries to help achieve much more complex animations are:

  • Anime.js
  • GSAP
  • Velocity.js
  • Threejs
  • MO.js

Reasons to use JavaScript to Animate

JavaScript is used for the following general purposes:

  • Adding interactivity to the user interface e.g. animation of key content to draw attention to it, guiding a user through submitting form.
  • Creating web, mobile and desktop applications. Because Javascript can be used for both client-side and server-side functionality, it makes it a great candidate to fast performing apps.  Developers benefit from using similar technology both client-side and server-side, as there are fewer languages required, and interactions between similar technologies has advantages.
  • Building web servers and server applications.
  • Game development. Although, very complex, multi-player games are more likely to be written in lower-level languages.

There are many reasons why JavaScript is the best choice to animate a website or web application, including:

  1. JavaScript is native to the web browser, meaning that it runs very fast.
  2. Whilst it is also possible to create animation within a website using CSS (cascading stylesheets), you can usually achieve the same thing (or better) in JavaScript more easily and with better browser support.
  3. It is a very popular language, which means that there are plenty of resources available when a developer is attempting to achieve a particular user interface.
  4. It has a very large online community, which provides strong support for learning and developing.

Although, it isn’t the only choice for creating animations, and for specific tasks might not be the right choice.  For example, the animated logo mentioned earlier might be better achieved using a .svg file, which is a special vector format image, that can be programmed to animate and retains perfectly crisp edges at any size.

When selecting a particular JavaScript framework, we consider the main features of each, and ensure that we choose a framework that will provide the right set of tools for the required solution.

When should a Website Avoid Animation?

We recommend that you should not include animation within your website or web application for the following reasons:

  1. Just because you can i.e. don’t animate everything and anything just because it is possible.  Animation for the sake of it can end up being annoying or distracting.
  2. To shift the location of web page content after page load.  Shifting page content can cause Google to penalise your website’s rank in its search engine results when Google determines that it is negatively impacting on the user experience.
  3. If it is unnecessarily slowing down the performance of your website / web application.

 

If you would like additional animation added to your website or web application, the Contactpoint development team is ready to help!

Facebooktwitterredditpinterestlinkedinmailby feather

Construction of a Native Mobile User Interface

April 5th, 2022 by Ishan Geeganage

More 6.64 billion people across the globe are using smart phones (and the apps on them). The majority of people use mobile applications for banking, searching for and ordering from restaurants, health, news, email and engaging on social media platforms.

A mobile user interface is the graphical and usually touch-sensitive display on a mobile device, such as a smartphone or tablet, which allows the users to interact with the device’s apps, features, content and functions.

In a mobile app, the icon is the first thing people see. The app icon design should aim to entice users to download the app, as well as help people quickly find the app on their device screen. Research has shown that an app icon can be a significant factor in the success or failure of an app.

App Design Considerations

Aside from the icon, when designing a mobile app, it is important to consider the following:

Navigation

Successful navigation is simple and intuitive, providing an obvious way to move between screens and functions. As many apps are used on very small screens, the effective use of screen real estate is very important.

Large touch area

Allowing sufficient space around controls will ensure that buttons, links etc are easy to tap using the thumb or finger.  Insufficient space and smaller controls will annoy a user and potentially cause them to make mistakes.

Simplicity

It is not necessary to display every possible piece of information on the interface. Organising content in a way that provides the user with a clear understanding of information, and allows them to drill down when they need more will allow you to reduce clutter and make using your app easier.

Larger text

It is important to keep text size in mind when designing for a mobile screen.  Designers work on a desktop computers to create app designs; it is important to constantly check that the text size will be easily readable once it is being seen on a mobile.

Use Native Controls

Many so-called native mobile controls are available to use within your app design.  These are controls, such as switches, list choices, buttons etc.  One of the benefits of building a native mobile app is that you have access to the native controls.  It is not a good idea to use simple web controls instead, as these are more difficult for the user to interact with, and the native controls are more expected by the user.

Available Components

Apple, unlike Android, does not have a dedicated “back” button.  When we are designing the user interface for a native Apple app, we need to address the Back button functionality.

In Messages, Mail and even Safari, a simple swipe right from the edge of the screen will navigate the user back to the previous window. This gesture also works in some third-party apps like Instagram.

Similarly, when we using the common screen elements like the Date Picker, Time Picker and Dropdown, we cannot produce the same look and feel for both iOS and Android apps. This is because these default components render a different look and feel in iOS and Android.

Use Simple Forms

Keep forms for user data entry to the simplest possible set of fields and options.  Use form controls to keep the need to type text to a minimum.  When building forms, there are various ways to help the user enter data, but keeping the design to the simplest possible in the first place is paramount.

Consistent Experience

If your site/app is present on both web and mobile, provide a consistent experience to the user.

Screen Structure

We need to consider the screen layout when designing the app. Apps can have different layouts, but there are many common screens which will usually have a layout something like the following:

mobile app layout

Images and Gradients

Wherever possible, instead of using images or image gradients, use colours and colour gradients to create in the same effect. Doing so will reduce the usage of complex images and therefore reduce the operational complexity of the app, thus improving performance of the app.

Building an App User Interface

Planning is very important before we write any code in order to convert an app design, into an actual functioning app.  The following activities are involved in building the design for a native mobile app.

Cutting up images

iOS

A standard-resolution display has a 1:1 pixel density (or @1x), where one pixel is equal to one point. High-resolution displays have a higher pixel density, offering a scale factor of 2.0 or 3.0 (referred to as @2x and @3x). As a result, high-resolution displays demand images with more pixels.

For example, suppose you have a standard resolution (@1x) image that’s 100px × 100px. The @2x version of this image would be 200px × 200px, and the @3x version would be 300px × 300px.

Android

To provide good graphical qualities on devices with different pixel densities, we need to include multiple versions of each image in your app—one for each density bucket, at a corresponding resolution. Otherwise, Android will scale your image so it occupies the same visible space on each screen, potentially resulting in scaling artifacts such as blurring.

For example, if you have a image that’s 48×48 pixels for medium-density screens, the following size images need to be included within the app:
• 36×36 (0.75x) for low-density (ldpi)
• 48×48 (1.0x baseline) for medium-density (mdpi)
• 72×72 (1.5x) for high-density (hdpi)
• 96×96 (2.0x) for extra-high-density (xhdpi)
• 144×144 (3.0x) for extra-extra-high-density (xxhdpi)
• 192×192 (4.0x) for extra-extra-extra-high-density (xxxhdpi)

app development

Using default icons

iOS and Android provide access to a small number of system icons. These built-in icons are available for common tasks and types of content. Every system-provided image has a specific, well-known meaning. To avoid confusing users, it’s essential that these system icons are used in accordance with its meaning and recommended usage.

iOS

standard app icons when building a mobile app

Android

Android standard app icons app development

Layout Construction

iOS

Auto Layout is a development tool for constructing adaptive interfaces. Using Auto Layout, we can define rules (known as constraints) that govern the content in an app. For example, we can constrain a button so it’s always horizontally centered and positioned eight points below an image, regardless of the available screen space.

Auto Layout automatically re-adjusts layouts according to the constraints we specify for certain environmental variations, known as traits. We can code an app to dynamically adapt to a wide range of traits.

auto layout use when building a mobile app

Android

Android provides an XML vocabulary for ViewGroup and View classes, which means that most of the user interface of an Android app is defined in XML files. The Android Studio’s Layout Editor is used to assist in the creation of the user interface; it writes the XML as the programmer drags and drops views to build out an app layout.  Fine adjustments can then be made within the XML if required.

building an Android mobile app interface

Code Manipulation of the user interface

iOS

The Interface Builder editor within Xcode makes it relatively simple to design a full user interface without writing any code. Simply drag and drop windows, buttons, text fields, and other objects onto the design canvas creates a functioning user interface.

We can independently design interfaces, separate from their implementations. User interfaces are actually archived Cocoa or Cocoa Touch objects (saved as .nib files), and iOS will dynamically create the connection between UI and code when the app is run.  It also assist developers to re-use common design elements.

Android

The Layout Editor enables us to quickly build layouts by dragging UI elements into a visual design editor instead of writing layout XML by hand. The design editor can preview a layout on different Android devices and versions, and we can dynamically resize the layout to be sure it works well on different screen sizes.

Supporting Libraries

We can develop custom screen designs without using third-party libraries, but certain libraries are very beneficial for efficiently building highly customised designs.

For both iOS and Android there are numerous libraries we can use for custom components like alert, popup, chat and animation.

iOS examples:
• LoadingShimmer
• ViewAnimator
• AnimatedCollectionViewLayout

Android examples:
• GarlandView
• InfiniteCards
• SparkButton

Testing

Once we have completed the build of an app – that’s implementing both the design and the required functionality – then it is imperative that we undertake thorough testing.  As a developer, I will thoroughly test my app, but it is also important that an end user tests it as well, as they are likely to uncover issues that I have considered.

Mobile application testing is very different from software testing and website testing. We need to consider the following before performing mobile application testing:

  • Screen resolution (different screen sizes in both iOS and Android)
  • Screen orientation (landscape, portrait)
  • Different devices’ manufacturers (only for Android phones)
  • Different operating system versions in both iOS and Android can have an impact
  • Changing a system settings like font size, themes and dark mode
  • Turning on/off GPS and incoming calls

This article provides a simple overview of what’s involved in building a design into a functioning mobile app. If you have questions, please don’t hesitate to get in touch.

Facebooktwitterredditpinterestlinkedinmailby feather

Spot the Odd One Out & User Interface Design

January 30th, 2022 by Heather Maloney

Do you remember playing the game “Spot the Odd One Out” when you were a kid? I used to love that game (yep, there’s a reason I ended up working in information technology) and it turns out that this is an important skill when working on user interface design for software and mobile apps.

As websites and web applications grow over time to fit in new information / functionality, our clients can be tempted to say something along the lines of “just add new function / information x into the menu / screen y”. The fact that they needed to say “just” is a strong indicator that it doesn’t actually fit there … they are introducing “the odd one out”.  It’s at this point that the rot is setting in! What started out as a well thought through information architecture has just been muddied. One quick decision, or many little decisions like this over time, will lead to a confusing user experience.

But how to explain the Macca’s kiosk app, and the location of the Decaf option?

One of the outcomes of the pandemic has been the expanded installation of kiosk machines at the front door of MacDonalds, which patrons are encouraged to use to place their order rather than walking up to the counter and telling the assistant what they want.  [I hope they disinfect the screens regularly.]

Have you ever tried to order a decaf? [Okay, I know that particularly if you are in Melbourne you are saying in your head “What??!! – decaf? Of course not!” but go with me on this, some people do actually drink decaf even in Melbourne.  In my case, caffeine just interrupts my sleep.  Sometimes I like a hot milky drink, and don’t want to load up with sugar (i.e. hot chocolate) so a decaf is great.

These are the steps to order a decaf via the Maccas kiosk machine:

  1. Press the Start Order button.
  2. Choose McCafe Drinks.
  3. From the McCafe Drinks menu, choose from:
    1. Cappucccino McCafe
    2. Latte McCafe
    3. Flat White McCafe
    4. Long Black McCafe
    5. Mocha McCafe
    6. Hot Chocolate McCafe
    7. Espresso McCafe
    8. Macchiato McCafe
    9. Piccolo Latte
    10. McCafe Deluxe Iced Coffee
    11. Iced Chai Latte McCafe
    12. Iced Mocha McCafe … (there are more options)
      I want a Decaf Flat White, so I choose #3.
  4. Choose your type of milk.
  5. Click Customise (on the assumption that you actually noticed that button, and didn’t end up on the order summary screen before it was too late).
  6. The top of the customise screen allows you to choose how many espresso shots are in your coffee.  Then underneath that is a list of additional ingredients.  This list starts with sugar packet, chocolate powder and Splenda.  You have to scroll down past the bottom of the screen to finally arrive at Decaf.  Press the up arrow for the number of shots to choose Decaf.
  7. Press the Save Changes button at the bottom of the screen.
  8. You are then presented with the “May we suggest…” set of options i.e. would you like fries with your order.  Press ‘Not Today’.
  9. You are then presented with Your Order.  Press Complete Order.  (There are sub options on this page for donating to a charity).
  10. You are then presented with the payment options screen, in which you have to choose either you want to pay by card or pay at the counter.  Press the large ‘Contactless’ button.
  11. Via the PIN pad next to the kiosk make your payment.

That is a total of 11 steps.  But, if you are like me and you choose Drinks first, before realising that it doesn’t contain the coffees, and you miss seeing the ‘Customise’ option and have to find that from the order summary screen, you can add another 3 – 5 steps to the above.  Feeling charitable, add a couple more steps again.

user interface design for mobile apps

It took me about 5 trips to Maccas to figure out that you could order a decaf via the kiosks.  In prior trips, I either went without, or bailed half way through my order and went up to the counter and ordered in person even though they wanted you to use the machine instead.  Once, a staff member tried to show me how to order a decaf via the kiosk, but gave up in favour of going back behind the counter and placing my order from there.

Perhaps the reason it took me so long to figure out is because, to me, Decaf is a different drink, it’s not a customisation of a coffee, just like Peppermint Tea is a different drink, and not a customisation of black tea.  If I wanted to order a decaf, why would I ever think “oh, I’ll start by choosing a caffeinated coffee?”  The McCafe Drinks menu includes hot chocolate, so why not Decaf?  Now that I have turned my mind to the question, I think I know the answer; it’s because it is conceivable that I might want a decaf latte, or a decaf long black etc.  Maccas probably don’t sell enough decafs to worry about including a decaf version of all the different types in the main set of options, so they added it to the list of customisations instead.  So my frustration is caused by inappropriate categorisation of items, and an obscure customisation process.

I’m very computer savvy, but it takes me (even without getting a decaf) about 3 times longer to place an order through the machine than it does to place an order via the person behind the counter.  This is in part the result of the kiosk user interface being filled with upsells and question after question.  At the counter, I can place my order with one statement (“May I please have a standard, flat white, decaf, with regular milk”) answer one question about taking away, and then tap your card.  Done.

Maybe the kiosk should allow you to speak your order to the machine?  I wonder what the Macca’s store statistics are telling them about the success of their new kiosks as the primary customer interface?

The above anecdote shows why careful thought needs to be given to user interface design.  Your website’s navigation menu is a user interface, just as much as the screens of a mobile app or kiosk software.  The general public will probably put up with a less-than-ideal user interface in a Macca’s store, because they are already there and know what they are going to get, even if they are frustrated when placing their order.  But a person using your website / app might not be quite so patient with your organisation.

Good user interface design will ensure that all the most commonly used tasks are intuitive for the user to accomplish, and involve the minimum number of steps.  Buying a decaf was probably, rightly, low on the priorities of the Maccas kiosk software designers.  What do you think of the kiosks, or are you skipping them in favour of drive through (voice ordering), or another vendor altogether?

What’s the most frustrating user interface you have to use?

Facebooktwitterredditpinterestlinkedinmailby feather

Why is the Development of Custom Technology so Complex?

September 14th, 2021 by Heather Maloney

why is custom technology so complex to build

Or maybe you are asking, “why doesn’t the IT team, or the company from whom I bought my software, get it right the first time?”

The fact is, custom technology really is complex. You’d think that with the number of years we all have under our belts, creating custom solutions to run in web browsers and on mobile devices, that it should be really quick and easy now to create something new. But in fact, the opposite it true. So, let me help you understand why that is the case by taking you through all the different facets that need to be addressed by that simple piece of custom technology you have in mind.

User Interface Design and User Experience … the way it looks, and the way people interact with it
To be successful, there’s no doubt that your custom technology needs to look good – modern, delightful, familiar but also match your brand so that it doesn’t jar with how your organisation appears in other places. Familiarity is important, so that your user doesn’t have to think too hard about how to achieve a particular task, but you don’t want your software to look the same as every other application so that your users don’t remember which software they are using.

User Experience can be constrained by the platform on which your application is to run. Is it operating within the constraints of a browser, or the constraints of a mobile app running on Apple’s operating system? Browsers have always been a source of angst for software developers. They are (now) free, but they come from different creators, and so have their own nuances. They are meant to follow standards, and these days generally do, but some browsers have implemented more of the standards than others. So you may find that one piece of functionality works perfectly in browser x, but is broken in browser y. There are usually ways around the problem, even if that way is to degrade gracefully, but they all require effort to resolve.

User Experience also needs to cater for different types of devices – mobile devices with touch screens provide a different mechanism for users to interact with the interface compared to people using your software on a desktop computer. Watches, digital pens, tablets … they all have quirks that your software needs to be aware of if it is going to run successfully on those devices.

Performance
Closely tied to User Experience is performance. Users of applications and web pages expect it to load quickly and process what they have submitted quickly. The way that an application is built needs to consider performance every step of the way. Perceived performance may be impacted by the speed of a particular user’s internet connection, the power of their hardware, the amount of memory available on their hardware, the amount of data flowing between a cloud server and the application, as well as the way the software is written.

Adding lots of features or complexity to one screen can impact on performance, and so careful consideration needs to be given to how much can be done on the one screen.

Caters for Every Scenario, and does what it is meant to do
One of the most difficult tasks in creating custom software is ensuring that it caters for every scenario. The person who describes how the software needs to operate has to think about not just the right way that a task should be done, but also all the variations that might occur, and how to handles those. For example, say you are building a To Do List application (because we absolutely need another one of those!), will your users want sub-tasks, will they always want to automatically tick off the main task once all the sub-tasks are done … the questions can sometimes feel endless.

When building software, it must help the user to know the right way to use the software, help them when, for whatever reason, they can’t follow the “right” way, and give them clear error messages and instructions on how to solve those errors when they get something wrong. We call this “data validation”.

Device and Platform Constraints
You may be of the view that whatever you can conceptualise can be built in software. That’s true to a degree, but unfortunately the device upon which your software will run comes with constraints. If you choose to have you software deployed as widely as possible, you might decide to build for both Apple devices and Android devices. These devices, particularly Apple, place many constraints on what the software can and can’t do. In some cases, only Apple itself can take advantage of some of the hardware features, so just because an app that comes on your phone can do a particular thing, doesn’t mean that you can achieve the same feature.

An example constraint is that you can only pair with a small number of other devices for the purpose of sending constant information between your mobile phone and the device you have paired with e.g. a watch, a watering system, a temperature thermometer. So if your software idea for a mobile device was resting on pairing with unlimited numbers of other devices, you wouldn’t be able to do that, and we would need to devise another way of achieving your idea.

There are many other constraints for not only mobile devices, the more common being:

  • screen real estate: how much you can fit on a screen and still be able to read / interact with it
  • memory: how much processing power at the disposal of your software before the computer appears to grind to a halt while carrying out a task
  • disk space: how much information you can store locally on the computer your software is using

Easy to Use
Ease of use was touched on above, but is an important characteristic in its own right. Ease of use is partly achieved by a familiar user interface design, and a well laid out set of interface components. But ease of use also relates to the task at hand, and how most people would normally think about a task they need to achieve via a computer screen. It may be impacted by the user’s environment, and also the information that they need or actions that they may have had to take before they needed to use your software.

Ease of use also considers factors such as whether the user can tab from one form field to the next, can use keyboard shortcuts, or whether they have to use a mouse to carry out certain tasks.

People have never taken in large numbers to reading help manuals, so strategically placed tool tips and text instructions / placeholder text are very handy ways to improve usability. Error messages, strategically placed, and delivered early (for example immediately after entering something wrong) will often help with usability.

Accessible (WCAG)
Accessibility, while not mandated, is a very important consideration. It takes ease of use about 3 steps forward, incorporating into your user interface a range of attributes that enable people with disabilities to use every aspect of your software just as if they didn’t have that disability. For example, transcripts for video or audio content provides those without hearing access to the spoken content in those digital assets. You can read more about accessibility in our blog post about the topic of accessibility in web browsers.

Caters for Future Uses
When we build custom software it is always important for us to understand the roadmap of features planned or hoped for a future version of the application. This helps us to cater for that future in the architecture of the first version of the software. That’s not to say that you can’t later go in a completely different direction, but knowing where you are heading means that we can allow for the expansion of the features to be more easily incorporated late.

This is most often felt in the area of the data and navigational structures of your application, where, without forward planning, your software can start to feel like a collection of functions that have been bolted together disjointedly … because that’s actually what happened!

Integrates with 3rd party solutions
Integration with other software solutions provides many benefits including:

  • you don’t have to build everything from scratch.
  • you can take advantage of the pre-existing user base of the software you are integrating with, potentially providing your software as an add-on to their toolset.
  • your software is more useful to your users because it is operating in an ecosystem.

Reasons why you might want to integrate with other systems include:

  1. marketing automation purposes – triggering email marketing to a new user, for example
  2. analysing the behaviour of users – what areas of your system are getting the most use, which ones are generating errors
  3. sharing data with other processes, your accounting function, for example
  4. adding data from other systems, such as the current weather, postcode and address lookups … the options are endless
  5. triggering additional processes, such as ordering components, setting up a meeting …
  6. notification purposes – keeping people involved in your work in the loop
  7. and much more!

Integrating with other software requires work, and careful thought. Where your integration involves 2 way data sharing, you need to identify where the master source of information is going to reside. You will also need to determine what happens when data comes back, if something has changed in the interim in your software? And there are many more questions to be answered with regard to integration.

Secure
The proliferation of cyber attacks on software means that security of your software solution is paramount. However, there’s a cost with the implementation of security, as well as usability trade-offs. It is important to understand upfront the level of security you need to build into your application, which will be different for a banking application compared to a To Do List application.

For example, secure applications interrogate every piece of data that is submitted into it, checking that it is of the allowed type, length and does not contain a malicious payload. Secure applications store and pass all data in encrypted form. Secure applications have a layered approach, adding extra checks for access between the layers.

An application that is secure one day may not be the next … hackers are continually looking for ways to break into systems. A code library that has been built into your software may tomorrow be exploited for the first time by a hacker, and then the creator of that code library (assuming they know about the hack) will need to close out the vulnerability and distribute a new version of their code library. It’s then up to the development team to bring in the new version of the code library, ensure that your software still operates correctly, and then re-deploy the new version. It’s a bit of a cat and mouse game unfortunately.

Keeping your application secure is one of the reasons that regular maintenance is required for all software applications.

Scalable
The ability for your software to be used by large numbers of people simultaneously also needs to be built into the architecture upfront, if that’s the intention. Scalability comes at a cost, although cloud application platforms such as AWS, Azure and Google Cloud have made it more easy to scale up your processing power, and distribute your solution across multiple servers and geographic locations, with greater ease.

Easy to Maintain
The first version of your software will not be the last. Usually a person with an idea for software determines the features that comprise their “minimum viable product” – enough functionality to inspire someone to use and pay for the software, or switch from a competitor product to yours – and then has that built and launched as quickly as possible. After that, continued investment is made in improving features to keep ahead of any competitive changes, and also to keep users happy that they can see improvements over time. Decades ago people were content with the software they bought on day 1 and didn’t expect (or want) any changes. Those days are gone!

Therefore, it is very important that your software is easy to maintain into the future. This characteristic is determined by things like: what language is my software written in – is that easy for developers, well-known in case I need more developers, as well as the platform that your solution is built and deployed on. Some platforms make it easy to make incremental changes and deploy those quickly.

You may also want to be able to update the content within your application – enabling this requires extra work to be done during the build of the application, as well as having security implications.

Documented
Finally, are partly to assist with some of the factors mentioned above, it is very important that your software is fully documented as it is being built. This can be a time consuming task, but it is vital for future ease of maintenance and enhancements. It will help you, developers and support teams to remember how the software is constructed, and efficiently deal with issues or correctly implement enhancements into the future.

As part of developing software, it is also important to keep version history on the development of your software overtime. This provides peace of mind that it is possible to revert to a previous version, should the need arise. Backups of the software are also important.

Solutions to the Complexity

The complexity described above means that creating custom software is not for the faint hearted! There is definitely a case for using pre-built / off-the-shelf software which you can read more about here.

There are also many ways to help reduce the effort required to deal with the above, for example:

  • Design frameworks. Material design is a prime example, where the team at Microsoft have created a collection of user interface components for icons, buttons, forms, cards and other user interface devices, which you can pick up and re-use in your own branding colours. These collections are often used as the starting point for a user interface design, with uniqueness added for more special functions of your particular application, as well as differentiation through your brand.
  • Code frameworks. Similar to design frameworks, code frameworks help for faster development by having commonly required features available pre-built. Things like standard animations, sorting elements, working with collections of elements. Without code frameworks the effort required to build custom software would be massively bigger. The choice of code framework employed for a particular software solution will depend on the type of application being built, and therefore the components likely to be the most handy to get the job done. Coding frameworks also assist in the implementation of security, with most frameworks being structured with maintaining security in mind.
  • Cloud development environments. This is similar to code frameworks, except that the development environment provide different types of pre-built component. For example, Amazon Web Services (AWS), Azure and Google Cloud, all provide a platform for hosting online software, along with components that are pre-built ready for use within your solution. Cognito is an example of a component available through AWS, which is used by many applications to handle to job of authenticating users into your application.
  • Integration middleware. To help integrate your software with another online solution, it might be expedient to use a middleware platform such as Zapier or Automate.io (there are others) to use their middleware to connect to the destination application. This will definitely be faster during an application prototype phase, even if it doesn’t get you everything you need into the future.
  • NO SQL / Document databases. These modern database platforms allow more flexibility to easily grow your data model to cope with any type of data you decide to add in future, which can require more work if you are using a relational database, although they have their place depending on your application.

If you are considering engaging a development team to build custom software for use by your organisation, or for the purpose of selling to other organisations (or maybe both!) please get in contact so that we can help you plan the successful development of your idea.

We’ve been designing and building custom software for more than 15 years, so we’re up for the challenge! Below are links to just a couple of examples of our work, if you would like to read more:
Scinogy Centrifuge Protocol Builder desktop application
Toll Group – Toll Transitions Pre-Removal Visit and Carrier Inspection Android App

Facebooktwitterredditpinterestlinkedinmailby feather

Custom Technology or Packaged Solution – which path should I take?

March 14th, 2021 by Heather Maloney

Contactpoint has always operated in the custom technology space, helping our clients with ideas for unique technology solutions to marketplace challenges, to make those ideas a reality. We are currently in the middle of building some significant pieces of custom tech, and we have just finished the complete re-build of a custom solution for Deaths and Funerals (we built the previous version of the solution many years ago, and the requirements had changed significantly).

However, not all of our work involves custom technology, and as much as possible we utilise pre-existing, proven technology and components to reduce the cost of custom development and ongoing maintenance. In addition, we are currently assisting several long term clients to move away from their own custom technology which we built for them, over to a packaged (aka ‘off-the-shelf’ solution). At the time when we built their original solution, that was the right option.

We recently discarded a custom technology that we had built for ourselves over many years in favour of a packaged solution – that technology is our project management software. On the other hand, we continue to support and enhance another custom technology solutionEnudge – which we built to service a very particular need in the marketplace, and of course we continue to use it for ourselves. You are probably reading this blog because we emailed you about it using Enudge.

All of the above begs the question: when should a business choose to develop a custom technology solution, and when should they choose a packaged solution?

To answer that question, I will take you through the advantages and disadvantages of custom technology.

Advantages of Custom Technology

Own the space
Creating your own custom technology, if successful, can allow you to be the dominant player in a particular market; that’s what I mean by owning the space. Your solution is unique to the particular problem you are solving, allowing you to do it better than your competitors, and therefore to stand out from your competitors. If you are using a packaged solution purpose built for your industry, then it will not be a factor in your market differentiation … you will have to look elsewhere for uniqueness.

Innovate
Most likely you will choose to build a custom solution because there’s nothing on the market that does exactly what you want – you want to innovate compared to what is already available because you have worked out a way to do it better, to achieve better business outcomes and better results for your customers.

Having control of the solution you are using gives you the opportunity to continue to innovate. Many of the packaged solutions that are available for your purchase were originally developed by a business who wanted to operate better, and then they realised that the solution they had made had widespread appeal for other businesses, so they pivoted (or spun off) into a software company instead of their original business.

Competitive Advantage
Innovating / improving the standard way things are done can give you a competitive advantage. Perhaps you can operate cheaper than your competitors, allowing you to perform the same service for a lower cost, and still achieve the same level of profit, or you can achieve a better / quicker result at the same price.

Where most businesses in a particular industry are using the same processes and technology solutions, then you can’t gain a competitive advantage from your technology.

A warning though: when your uniqueness in the marketplace is largely delivered through your software solution, you need to keep on your toes as many software solutions which just involve what is known in the industry as CRUD operations (create, read, update and delete) are relatively easy for a competitor to copy. In this situation, continually innovating will be essential to keep you ahead of your competitors.

Packaged solutions also continue to innovate, but every business using that solution will gain access to the same innovation at the same time. You might have the opportunity to pitch an innovation to the packaged software vendor, but they will have a very long list of planned features – whether your suggestion is ever implemented will be unknown. And if they do, all your competitors using the solution receive the advantage as well.

Agility in the Marketplace
The economic and legislative landscape in which you operate will change over time. Customer behaviour will change with fads and trends. If you control your technology, and if you have the funds, you can be the first to take advantage of a new opportunity that arises as the result of a new trend.

Reliability into the future
Finally, and something I expect businesses are thinking less and less about that the moment because of the largescale move to cloud technologies which force you to rely on the big tech companies, owning the technology, and having control over it’s future, gives you certainty for the future operation of your organisation.

I don’t expect the big tech companies to disappear anytime soon. However, what about the packaged solution you are using for, say, your project management. What would be the business impact of your organisation if that company decided to sell or close down? This is a factor you need to consider when choosing a packaged solution and is largely resolved by building your own.

Disadvantages of Custom Technology

Expense
There’s no getting around it; building your own software, even if you hired a teams of designers and developers directly, will cost considerably more than buying a packaged solution.

Nearly all software runs on hardware and/or platforms that are built and managed by other businesses. That means that your custom-built software solution will need to be continually maintained in order to ensure it will run on newer hardware and will continue to operate correctly when the platform is updated including web browsers (where your software is run through a browser).

When you are the only organisation using your software you may not be able to achieve the economy of scale that a packaged solution can. Selling the one solution to a large number of companies is a way to amortise the cost of the development and ongoing maintenance.

Organisations for whom we build custom software will often have the potential to apply their custom software to multiple businesses, or to a franchise, or are indeed intending to have a significant share of a large market.

An Ongoing Project

I’ve already touched on this under the topic of Expense, however, the other disadvantage of custom software is that you can’t just build it, and then enjoy using it. You have to be committed to the software over the long term. You have to be willing to dedicate time and effort to maintaining the solution to keep the benefits you have gained from your investment – this time and effort may be a distraction from your core business.

As a minimum, your software will need to be maintained to continue to work with new versions of the hardware and/or platforms upon which the software is running. You will need a good software partner (like us!) to continue to maintain and support your solution on an ongoing basis.

If you have moved into the business of delivering a software solution to other organisations, then you need to continue to innovate in order to stay at the top of the list of solutions. Similarly, if your technology solution is your competitive advantage, you will want to focus on ongoing improvements to keep your competitors at bay.

In conclusion …

By way of summary, the advantages are all about opportunity, and the disadvantages all relate to investment (time and money).

It is my view that you should embark on creating custom technology when both of the following are true:

  1. There is no well-supported packaged solution that fulfils all your most important requirements or complete ownership of the solution is vital for your competitive advantage, and
  2. You have the ability to fund not only the initial development but also ongoing maintenance and enhancements. This might include revenue generated from the sale of the solution if that’s part of your strategy, or it might be that your solution will reduce your costs, or enable you to expand into new markets without increasing your costs.

Where our clients are now moving away from their own custom technology to a packaged solution, it is because there is now available sufficiently robust solutions to meet their key requirements, and / or they no longer have a good enough reason to maintain their own solution. In addition their custom solution no longer provides a competitive advantage and is not their core differentiation in the marketplace. It may also be too expensive to maintain, or too distracting from their core business.

There is one other alternative that should also be considered for creating a custom technology solution: using a configurable platform, instead of building from scratch. A platform that enables you to combine components which, together with an underlying data store and workflow rules, creates your required technology. Often these platforms are low code or no-code solutions, providing drag and drop user interfaces to create the system. There are myriad models for such solutions. WordPress is a kind of this solution, whereby you can add plugins to your existing WordPress website to achieve additional functionality often without needing to write any code. Hosted form builders, including Microsoft’s Sharepoint combined with Power Automate and Power Apps, is another example applicable to organisations using Office365.

Cloud platforms such as AWS, Microsoft Azure, and Google Cloud Computing are also helping the development of custom software solutions more accessible to small business via the pre-built components they provide in their cloud platforms – we make use of these for many of our clients to reduce the cost of development of custom solutions.

Making the right choice of platform on which to build your custom technology solution, or choosing the right packaged solution, is a very important decision. Making the wrong decision can be very costly, either in opportunity and position in the marketplace or in dollar terms. If you would like to discuss your idea for custom technology, don’t hesitate to get in touch. We are invested in your success, whether that’s pointing you to a packaged solution or helping you create the technology to underpin your invention.

Facebooktwitterredditpinterestlinkedinmailby feather

Why not offshore my app development project?

April 17th, 2017 by Heather Maloney

Okay, you’re going to think I’m bias – I own a web & mobile app development company based in Melbourne, Australia, so of course I want to discourage organisations from offshoring the development of their apps.

Australian technology design and development

However, fact of the matter is that I’ve heard countless war stories of offshored developments that have gone wrong … either the whole development has been thrown in the bin due to a poor quality result, or a project that was meant to be delivered by a particular date for a specific cost has escalated in both time and cost. My organisation has been the beneficiary of such malfunctioning projects, but not before the organisation has been through months of pain and disappointment prior to arriving at my door.

Apart from the issues of getting what you actually want, in an appropriate time, and for the low cost you expect from offshoring, there’s a third concern – security of your intellectual property. How do you really know that your solution isn’t being re-used for other foreign organisations to achieve the same or similar outcomes in their local market or the global market? If you needed to pursue a competitor for theft of your IP, doing that in a foreign country is going to be exponentially more difficult than locally. The risk of reputational damage to a local provider also provides you with additional leverage if an issue arises.

So why do off-shored projects so often go wrong? Anecdotally it would seem that the following issues are the primary reasons:

  1. Communication – first and foremost, effectively communicating your requirements is best done with the person/s carrying out, or at least overseeing, the development in the same room. Offshore developers try to overcome this with business analysts in Australia preparing vast documents on the required solution, adding time and cost to the project. Because the analysts are primarily in Australia, passing on of the information usually relies on the developers reading the vast amount of output and then following it … again inefficient, and developers aren’t known for wanting to read long documents before they start coding.
    Offshore developments usually require additional management in order to manage the offshore teams and co-ordinate communication, reducing the benefit of the lower developer hourly rates.
    Agile methodologies require close proximity of the developers and the clients to be successful.
  2. Time Zone – the effect of working in different time zones almost always adds to the project timeline. Someone has to wait until the start or the end of the day to communicate with the team, and when one team is working, the other isn’t, making asking a quick question in order to keep progressing down the right path either very difficult, or adverse for the work-life balance of team members.
  3. Cultural Differences – written English is heavily subject to interpretation. Cultural differences can increase the likelihood of incorrect interpretation. Trying to achieve a solution that feels like it was built for the Australian marketplace is also less likely from an offshore team, which is why design (UI & creative) is rarely carried out offshore.

From time to time I am asked to manage an offshore team in order for a client to get the benefit of lower cost developers. I always politely decline. We are able to develop great solutions, in a timely and cost effective manner because we have our developers in the same room, can have efficient discussions and decision-making about the developments if a difficulty arises, and because our clients are also close to the developers when the need arises. We also bring to our clients many years of experience, industry knowledge and of course cultural understanding.

There are times when you can’t get the resources you need, when you need them, locally such that offshore is the best option. But perhaps you should instead consider breaking down your development to smaller chunks so that a smaller, local team can meet your requirements. Smaller developments of shorter durations are also more likely to be successful, cost effective and deliver value to your customers and organisation more rapidly.

If you require a web or mobile application to be developed, I’d love to discuss the potential opportunity with you, so don’t hesitate to get in touch.

Facebooktwitterredditpinterestlinkedinmailby feather

Subscribe to our monthly

Contactpoint Email News

Our enews is sent out approximately monthly, and contains information on latest digital technologies, and how these can be used to help your organisation grow.

To subscribe, simply fill in your details below: