Category: Development

I have several projects I support which had/have long development times. When I say a long development time, I don’t mean bug fixing and support issues. I mean continued development of significant new features or modules.

In this blog post I have two examples, a long-term project for a client which I have been building and adding to for 18 months and the API for Costs to Expect which I have been working on for several years.

One of the significant issues with long-term development projects is ensuring the App design remains consistent. There are many reasons why you might want to change or tweak the design of your App. The original design might not be right as you get further into the project. You think of a better way of doing something or a new tech comes out which could significantly improve things.

The client matters

What you do very much depends on the type of project.

If the project is a personal project, you are free to do what you want. With personal projects we are free to decide when architectural changes make sense and when to do them, it is bliss.

However, if the project is for a client, things get much more difficult, and it depends on your relationship with the client. If you are a contractor, the best you can do is submit a request and explain any benefits.

When you are a freelancer or know you will be supporting the project for a decade or so, it is complicated for a different reason. If it will benefit you to makes the changes, you must decide if it is worth just buckling down and making the changes. There have been instances where I have made changes at my own cost. Many a time I have spent a week or so making some major changes knowing that they are going to make my life easier later.

Some of the time I’ve made these changes for ‘free’, some of the times I’ve been paid. For me, it depends on who benefits. If the only benefit is my time in the future, I tend to make the changes for free. If the changes have the potential to make my life easier and somehow enable additional features in the future, I suggest the changes and try to get paid.

Conclusion

There is no perfect answer. We can’t always predict when we are going to support an App for over a decade. We can also get it wrong. There have been times when I’ve adapted the design and it turns out, it wasn’t for the best.

We are all still learning, it’s one of the things I love about our field. My advice, go for it; if you get it right, you win. If it doesn’t turn out how you’d hoped, chalk it up to experience.

As I’ve mentioned in previous blog posts, I spend a large part of my time working on B2B Apps for my clients, the sort of Apps that manage a large amount of data. UI (User interface) and UX (User experience) for B2B Apps is tough, especially when you are primarily a developer.

The Problem

I recently needed to build a small subsystem for a client and the brief was effectively a single row on a spreadsheet with at least twenty-two columns of data. I know, helpful right?!

The brief was fine, I knew exactly what functionality the client needed, the issue was creating an easy-to-use UI that had great UX. My solution couldn’t just be a duplication of the spreadsheet on the web.

The Solution

There were a couple of obvious improvements I could make immediately. If data is duplicated among the rows, I can create a hierarchy. This reduced the “width” of the data; however, I was still left with seventeen columns of data.

I split the data a little more and managed to break it down in such a way so that the largest repeatable section was eleven columns wide, this was workable. Due to the nature of the problem, these eleven columns need to be configurable together.

Initial Feedback

I got an example page working and although there was a lot of data, I could read it. I sent it to the client to review and they were happy although they found it a little tough to parse. This is a common UI problem, especially with B2B Apps that have a lot of data. As developers, we are close to the data and can easily parse it, but we need to think about the users.

Improvements

I took a step back and thought hmm, why is it difficult to read? There was visual separation between the data, but it wasn’t clear enough, I needed some colour and spacing. I alternated the colour of headings, ensuring consistency with heading types, added quite a bit more spacing and then boom, everything looked great. The client was happy

Now the UX

With the UI sorted I needed to work on the UX. The preview I showed the client was just for viewing the resulting data, we still needed all the management views and forms. For this I took the UI the client was happy with and added the relevant action controls, copy, edit, delete etc. Additionally, management pages only show a subset of the data, data that is specific to the action in question.

Still learning

As mentioned, most of the Apps I created are B2B. These Apps need to look pleasing, but the UX is far more important. I struggle with both, especially the UI. After twenty-five years creating Websites and Apps I’m still learning new tricks. One thing that I continue to overlook is spacing. You really do need to ensure there is enough spacing between sections of data, it is amazing how much difference a little space makes.

The blog post is part of a continuing series talking about a complex B2B App I created for a client. You may be interested in the previous blog post where I talk about needing to integrate with Business Central using OAuth2.